This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: why Glibc does use alloca?


On Fri, May 16, 2014 at 10:11:40AM -0600, Jeff Law wrote:
> 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.
> 
If you have idea then do it instead of just talking. Let gcc do
poisoning by default, so buffer overflow will not be exploitable unless user
turns off protection.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]