On 08/10/2016 12:33 PM, Richard Biener wrote:
Why would you want to get rid of the alloca here?
Do you know the range for LENGTH in the code above?
Yes, it's a set of tree code names.
Is it based on
something the user could potentially control (like a variable name,
typdef name, etc). If you don't know the length or it's possibly
under
the control of the user, then this can blow out the stack, which
makes the code vulnerable to a stack shifting style attack by which
further writes into the stack are actually writing into other parts
of the stack, the heap, plt or some other location. Essentially
this gives an
attacker control over one or more stores to memory, which is often
enough of a vulnerability to mount an attack.
Yes, I understand that. The above is not such a case. If an
attacker can trick me into compiling (and possibly executing) his
code then things are lost anyway. No need for a fancy buffer
overflow.
I think you're being rather short-sighed here. GCC is being used in
ways we can't necessarily predict -- which might include compile
servers, JITs, web services, etc.
In those kind of environments I think you have a significantly different
threat model and GCC itself becomes part of the attack surface.
There's existing web sites I'm pretty sure I could compromise if I had
the interest by exploiting bugs in GCC and libiberty.
Jeff
