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    [W:0.027 / U:31.872 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site