lkml.org 
[lkml]   [2005]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Patch 4/6 randomize the stack pointer
-----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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
\
 
 \ /
  Last update: 2005-03-22 14:10    [from the cache]
©2003-2011 Jasper Spaans