[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 -

    -----END PGP SIGNATURE-----
    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    [W:0.024 / U:24.064 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site