[lkml]   [2005]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Patch 4/6 randomize the stack pointer
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';
>>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 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
> Jakub

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

Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at
 \ /
  Last update: 2005-03-22 14:10    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean