On Sun, Jul 26, 2020 at 3:33 PM Paul Eggert <[email protected]> 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
