This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: why Glibc does use alloca?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Jeff Law <law at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Will Newton <will dot newton at linaro dot org>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 23 May 2014 13:23:15 +0200
- Subject: Re: why Glibc does use alloca?
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdw135gBO+cTQx3Ws1GrRgFsi8-j=Y_mZ=ixebpPzB4gXw at mail dot gmail dot com> <53760025 dot 10204 at redhat dot com> <CANu=DmhF=PZBVHtOPw5ZMCHjcy6vqdCvrRvY+xO9hzfkjTCRQA at mail dot gmail dot com> <53760826 dot 6090203 at redhat dot com> <20140516135304 dot GA29829 at domone dot podge> <537630BB dot 7030701 at redhat dot com> <20140516160903 dot GA2363 at domone dot podge> <537638BC dot 4090500 at redhat dot com>
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.