This is the mail archive of the 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]