On 06/16/2016 02:32 AM, Aldy Hernandez wrote:
Hi folks!
I've been working on a plugin to warn on unbounded uses of alloca() to
help find questionable uses in glibc and other libraries. It occurred
to me that the broader community could benefit from it, as it has found
quite a few interesting cases. So, I've reimplemented it as an actual
pass, lest it be lost in plugin la-la land and bit-rot.
And just to provide more background.
In my time caretaking glibc for Red Hat, unbound allocas were the single
most commonly exploited problem in glibc. They can be used for stack
shifting or under-allocating objects which in turn allow for the bad
guys to start scribbling data into memory at locations under the
attacker's control.
In fact, I saw this enough that I'm of the opinion that we as developers
simply aren't capable of using alloca correctly and that its explicit
use ought to be banned by policy. Anyway.....
Before I sink any more time cleaning it up, would this be something
acceptable into the compiler? It doesn't have anything glibc specific,
except possibly the following idiom which I allow:
I strongly believe it ought to be cleaned up and brought into GCC.
p.s. The pass currently warns on all uses of VLAs. I'm not completely
sold on this idea, so perhaps we could remove it, or gate it with a flag.
An VLA where the size is under attacker control is no different than an
unbound or overflowing alloca. Negative sizes in particular are easy to
exploit, though the same effect can be achieved overflowing the actual
size computation.
So I think this problem turns into whether or not we can see the size of
the allocated object and use that to guide warning. This also
introduces the idea of somehow marking objects which are under user
control (and propagating that property) and using that to help guide
analysis.
Jeff
