This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: alloca vs malloc
- From: Jeff Law <law at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, 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, 16 May 2014 16:00:09 -0600
- Subject: Re: alloca vs malloc
- 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> <Pine dot LNX dot 4 dot 64 dot 1405161626230 dot 18605 at digraph dot polyomino dot org dot uk>
On 05/16/14 10:58, Joseph S. Myers wrote:
On Fri, 16 May 2014, Jeff Law wrote:
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.
Allocation sizes in general are an issue.
Very true.
The cases that can do an
unbounded alloca (or VLA) are typically also subject to integer overflow
that would likely be exploitable for a too-small malloc as well.
I was primarily concerned with alloca buffers where we can blow out the
stack and those have been numerous. Integer overflow to a
too-small-malloc is a real issue as well.
E.g. bug 16618 (something I'd have
thought would be a natural case for a CVE - wscanf may not be widely used,
but it's still a buffer overrun if wscanf is used -
More likely nobody's contacted the appropriate folks. Sounds like it'd
be worth of a CVE to me.
My experience is that whenever I go looking for (integer overflow,
unbounded alloca / VLA, allocation size incorrect, use of "int" allows
large sizes to be truncated, ...) bugs in glibc, they are pretty easy to
find (though sometimes it may not be clear whether it's actually possible
for large sizes to arise in the given function, and I've just looked for
such bugs anywhere without regard to exploitability).
I've mostly been dragged in due to exploitable bugs and by far the most
common have been unbound allocas. I recall a single integer overflow
feeding a malloc and to exploit that required turning off some other
protection (can't remember which).
Any code in all of those historically risky areas could do with careful
review by multiple people and with different tools to help find problem
code, as well as use where possible of coding patterns that avoid the risk
of e.g. missing overflow checks.
Absolutely. I keep pondering writing a static analysis pass for GCC to
analyze sizes passed to alloc. Anything with a loop carried dependency
or which isn't a small constant would get flagged for further review.
jeff