why Glibc does use alloca?

[Jeff Law]

On 05/16/14 10:09, Ondřej Bílka wrote:
> On Fri, May 16, 2014 at 09:37:31AM -0600, Jeff Law wrote:
>> On 05/16/14 07:53, Ondřej Bílka wrote:
>>>>
>>> All you need is reliable way to get stack boundaries. I proposed to add
>>> these some time ago. It would make alloca failures reliable without
>>> need of gcc support.
>>>
>>> A better alternative than ten line boilerplate alloca with fallback to malloc
>>> would be using malloca, that handles these automatically. With stack
>>> bounds it could allocate fairly safely, without these it must resort to
>>> heuristic like size is less than 65536.
>> Better yet, stop using alloca.
>>
>> Seriously.  I don't have hard data, but there's little doubt in my
>> mind that if we were to look at CVEs for glibc, the majority are due
>> to unbound allocas.
>>
>> Experience clearly shows that we consistently get it wrong with
>> alloca.  IMHO, it should simply be banned from glibc (and
>> everywhere, but let's start small).
>>
>> Yes, I know it's orders of magnitude faster than malloc.  Yes I know
>> we get automagic cleanup.  But if using it consistently results in
>> incorrect code that attackers can exploit, then the performance
>> aspects really should take a back seat.
>>
> Problem is that security advice is useless when nobody follows it.
One could enforce such policy by poisoning alloca.

>
> There is additional dull knife risk. If alloca is not available then
> users that want performance will replace it with 64k arrays and malloc
> fallback which makes overflow more likely.
I'd hope patch review would catch this kind of sillyness.

jeff