Re: Patch 4/6 randomize the stack pointer

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jakub Jelinek wrote:
> On Sat, Jan 29, 2005 at 01:31:46AM -0500, John Richard Moser wrote:
> 
>>Finally, although an NX stack is nice, you should probably take into
>>account IBM's stack smash protector, ProPolice.  Any attack that can
>>evade SSP reliably can evade an NX stack; but ProPolice protects from
>>other overflows.  Now I'm sure RH is over there inventing something that
>>detects buffer overflows at compile time and misses or warns about the
>>ones it can't identify:
>>
>>if (strlen(a) > 4)
>>  a[5] = '\0';
>>foo(a);
>>
>>void foo(char *a) {
>>   char b[5];
>>   strcpy(b,a);
>>}
>>
>>This code is safe, but you can't tell from looking at foo().  You don't
>>get a look at every other object being compiled against this one that
>>may call foo() either.  So compile time buffer overflow detection is a
>>best-effort at best.
> 
> 
> If strlen(a) > 4 above, then -D_FORTIFY_SOURCE={1,2} compiled program
> will be terminated in the strcpy call.  At compile time it computes
> that the strcpy call can fill in at most 5 bytes and if it copies more,
> then it terminates.

And somehow you check every operation like this with less overhead than
propolice?

> 
> 
>>ProPolice protects local variables with 0 overhead; passed arguments
>>with a few instructions; and the return pointer and stack frame pointer
>>with a couple instructions.  At runtime.  Want to impress me?  Actually
>>deploy ProPolice instead of showing up 3 years from now waving around
>>your own patch that you wrote that half-impliments half of it.  If you
>>want "something better," it's GPL, so grab it and start hacking.
> 
> 
> __builtin_object_size () checking/-D_FORTIFY_SOURCE=n changes are (partly)
> orthogonal to ProPolice.  There are exploits prevented by
> -D_FORTIFY_SOURCE={1,2} checking and not ProPolice and vice versa.

So a belt-and-suspenders approach is better.

> Things that the former protects and the latter does not are e.g.
> some non-automatic buffer overflows or heap overflows, some format string
> vulnerabilities and for automatic variables e.g. those that don't
> overflow into another function's frame, but just overwrite other local
> variables in the same function.  ProPolice on the other side will detect
> stack overflows that overflow into another function's frame,

or past the top of any buffer by at most 2 ints (I didn't check with 1
int or 1 char when I wrote my regression suite), definitely before it
hits the SFP and return pointer

> even if they
> aren't done through string operations (<string.h>, s*printf, gets, etc.)
> or if the compiler can't figure out what certain arguments to these
> functions points to (and where) at compile time.
> 
> The ideas in IBM's ProPolice changes are good and worth
> implementing, but the current implementation is bad.
> 

Lies.  I've read the paper on the current implementation, it's
definitely good.  It only operates on C/C++ code though, but that's the
scope of it.

> FYI, you can find some details about -D_FORTIFY_SOURCE=n in
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html
> 
> 	Jakub
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+8yPhDd4aOud5P8RAsekAJsGklzrgWi7ymrRmfhXpqv2LjB//gCeNBDy
8sCZBhtzy6l6L/WDjQpMq6A=
=4/Dz
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/