This is the mail archive of the
mailing list for the glibc project.
Re: why Glibc does not build with clang?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Jeff Law <law at redhat 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:58:40 +0000
- Subject: Re: why Glibc does not build with clang?
- 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>
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. 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. Or the
size calculation is simply wrong. 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 - but I don't know how
people requesting CVEs for glibc bugs work out which are worth it). There
you have (a) allocation size for malloc is 4 times too small, (b) possible
overflow in calculation for very large allocations, (c) __libc_use_alloca
used with the wrong size so stack usage could be four times what's
> 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).
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).
Starting small might simply be tracking existing known bugs of that form
and ensuring they get fixed (e.g. bug 1291 - reported in 2005 - is as far
as I know still valid; or bug 16009 is basically the same issue as in a
CVE bug that got fixed only for another function). (In some cases you may
have a CVE but it may be unclear if it's really a security issue - e.g.
bug 16617 / CVE-2012-3406. In some cases, e.g. bug 14483 with int being
used for allocation sizes for obstacks, exploitability seems less likely,
although general principles of avoiding arbitrary limits still apply.)
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.
(And, generally, existing open bugs in most areas could still do with
review - with people taking on the role of being de facto experts in a
particular area, going through and fixing bugs and making sure when doing
so to check whether the same underlying issue might appear elsewhere in
glibc and trying to get the whole issue thoroughly fixed rather than just
one instance of it. "Security" could be one such area and could probably
do with multiple people finding and fixing (potential) bugs. There still
aren't that many people doing that much on glibc.)
Joseph S. Myers