Re: alloca

[Jeffrey Walton]

On Sun, Jul 26, 2020 at 3:33 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 7/26/20 6:50 AM, Jeffrey Walton wrote:
>
> > It is about reducing attack surface and risk.
>
> That's a good thing, but it's not the only thing. If all we cared about was
> reducing attack surface then we'd omit pointers, arrays, and recursion.
>
> This reminds me of the effort long ago to replace all uses of strcpy with
> strlcpy or strcpy_s or whatever. What a waste of time that was.

How do you measure success?

Several years ago I worked for a company that does the offensive
security thing. The company develops exploits. The company also had a
package that would plant itself on a mobile device, track the target,
turn on the camera and mic, egress data over a TLS-like channel
(complete with Diffie-Hellman key exchange), etc. The company sells or
licenses them to the government or one of its prime contractors, like
Northrop Grumman Electronic Warfare Division.

I recall a lot of exploits based on memcpy, strcpy and friends. I also
recall less frequent exploits on strncpy, snprintf and friends. It is
amazing how much the missing NULL terminator affects security for an
application.

I don't recall seeing an exploit based on memcpy_s, strcpy_s and
friends from TR-24731. The safer functions have a measurable effect on
an attack surface. With that said, I am sure someone has an exploit
based on the safer functions. I just don't recall seeing one.

When Gnulib fails to provide the safer functions of TR-24731, or when
GNU software leaks memory so tools like Asan, BoundsChecker, Coverity,
Enterprise Analysis and Valgrind cannot be used, it is playing right
into the attackers hands. The arrogance helps the attackers a lot,
too. The attackers are probably sitting back laughing their asses off
that GNU developers are being told these things but the developers
still ignore them.

Jeff