Re: why Glibc does not build with clang?

["Joseph S. Myers" <joseph at codesourcery 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 
intended.

> 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
joseph@codesourcery.com