Re: Buffer over-run vulnerabilities

From: AndyJ (andy_at_wild-flower.co.uk)
Date: 02/26/04 

Date: 26 Feb 2004 03:53:18 -0800

> More commonly (via stack buffer overruns) the inserted "data" contains
> an short piece of code that is executed when the calling function
> (that contains the buffer var) returns -- but the return address has
> been changed to jump to the inserted code (egg).

I must admit I hadn't thought about the stack angle (too long since
the time I had to bother about such things). Obviously it is
intrinsic in the way a combined parameter/return stack works, that
this type of vulnerability will exist, if you don't check your data
will fit into the space allocated! Separating them out (e.g. like
FORTH does) would obviously mean that all compilers would need to be
reprogrammed - obviously not practical.

>
> And this is a pretty fair description of a heap based overrun, which
> is not dependent on the "structure" of the stack, but on the structure
> of the heap var.

Understood.
 
> Especially so with stack based exploits -- when a function returns it
> jumps back to the point from which it was called while the exploit
> causes it to jump to the injected code instead. It's just taking
> advantage of how stack based vars and code work.

Understood.

> The stack operates the way it does out of "necessity" and is built
> into the compile time code. There are ways to use a non-executable
> stack. Heap overruns need to get to the vulnerable spot in heap
> memory, so they need a way to get a pointer to the right location --
> this is usually done by knowledge of the vulnerable code structure
> (and sometimes some good detective work with a decompiler).

Understood.
 
> You don't really have any control over the "absolute" location of code
> or data on the heap and that which is placed on the stack must be
> placed in specific (if automatic) ways.
 
> Your solution is a variation on the principle of "security through
> obscurity" , ie., hiding things good enough that others won't find it
> without the "secret knowledge" of how to get there. Makes getting
> there harder, but once there the same vulnerability exits to be
> exploited. The cure is to fix the vulnerability (the disease) rather
> than obscuring its presence (the symptoms).

Don't you *dare* use my stock come-backs on *me* ;-)... but point
taken. I was really thinking in terms of 'raising the bar'... adding a
bit more uncertainty would make exploitation more difficult - no one
way is going to solve all security woes! However, one of the defining
factors in cryptography is how easy it is to work out how the code
*works*, and the more unpredictable the results are, the more
difficult this becomes; I thought this might follow through usefully
onto programming. I agree that the best way forward is for people to
code responsibly in the first place, by always checking data size/fit!

Thanks for responding,
-andyj

Relevant Pages