Re: alloca

[Paul Eggert]

On 7/26/20 3:03 PM, Jeffrey Walton wrote:

> I recall a lot of exploits based on memcpy, strcpy and friends. I also
> recall less frequent exploits on strncpy, snprintf and friends.

I'm not surprised, as memcpy and strcpy are used a lot more than strncpy. And 
uses of strcpy_s are even rarer than strncpy.

When I looked into this topic long ago (this was when the OpenBSD folks were 
advocating strlcpy), I quickly found a bug in OpenSSH introduced by their 
wholesale replacement of strcpy by strlcpy. It wasn't a severe hole, but it was 
enough to convince me that this sort of "fixing" is not without its own 
problems. (Their wholesale replacement didn't fix any real bugs that I recall.)

> 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.

When Gnulib code uses unbounded alloca it is indeed playing into the attackers' 
hands, and these problems should be fixed just as Bruno said. But Gnulib code 
need not use TR-24731 to fix the problems. TR-24731 can be useful when you're 
trying to retrofit a lot of poorly-written code that you don't have time to 
think through. But it's not a good approach for every circumstance.

> The arrogance

Let's keep the discussion technical.