-----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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/