Re: [ANNOUNCE] glibc heap protection patch

From: Stefan Esser (se_at_nopiracy.de)
Date: 12/03/03

  • Next message: Martin Mačok: "XBoard < 4.2.7: pxboard insecure tmp file handling"
    Date: Wed, 03 Dec 2003 14:01:39 +0100
    To: William Robertson <wkr@cs.ucsb.edu>
    
    

    William Robertson wrote:

    > This is true in the case of the fd and bk pointers, and in fact this
    > is one of the checks that dlmalloc's debugging code performs.
    > However, as we also demonstrated in the paper, you are still open to
    > other heap-related attacks, such as overwriting size fields and
    > setting up fake chunk headers. So, unfortunately I don't think that
    > check alone is sufficient.

    The last time I checked there was no such check in the unlink macro (no
    matter if debug mode or not). Overwriting size fields and setting up
    fake chunk headers are the standard way to exploit malloc()/free()
    structures. And you should rethink about my unlink macro. It perfectly
    stops ALL
    heap attacks that try to make use of the unlink macro (and this are the
    most out there). I know that modifying unlink does not protect against
    frontlink attacks. But most heap exploiters do not even know that there
    is anything else than unlink. I never said that the unlink macro is the
    ultimate solution to all heap problems, but it is certainly securer to
    check the pointers on unlink than protecting it only with magic numbers.
    The best solution would be a combination of both.

    Ohh btw... Feel free to demonstrate me an unlink exploit that works
    while my unlink macro
    is in place... In the last two years I nearly only concentrated on heap
    exploits on a various
    number of platforms. glibc/bsd/solaris/windows and I even exploited the
    heap on XBOX
    with my dashboard-font exploit. So I very much doubt that my statement
    was incorrect.

    Stefan Esser


  • Next message: Martin Mačok: "XBoard < 4.2.7: pxboard insecure tmp file handling"