OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Exploiting overflow of heap-based buffers
From: Matthew Kirkwood (weejockferret.lmh.ox.ac.uk)
Date: Wed May 24 2000 - 11:53:32 CDT

On Wed, 24 May 2000, Solar Designer wrote:

> > Matt informed me that there's a class of malloc which use free()'d
> > areas to store objects pointing to free heap space.
> >
> > So if you can corrupt free heap space pointers, you could play interesting
> > games like mark the area of the stack containing the return address as
> > free. Or mark a few function pointers used by atexit() as free.
>
> There's usually a linked list (or several lists) of free chunks, and I
> don't know of a malloc implementation where you can mark something as
> free without having to write into that "something" as well. You can,
> however, control a memory write on a call to free(3), provided that
> things don't crash earlier.

The ideal exploitable code which we were thinking of was something
like:

        char *a;

        a = malloc(smallish_number);
        discover_the_buffer_is_too_small();
        free(a);

        // oops, here we write to the buffer anyway
        // (or maybe we overflowed some other heap variable)
        recv(fd, a, smallish_number, 0);
        // now we control the second entry in the free list

        // since bigger_number > smallish_number, we can't
        // reuse the head of the list
        a = malloc(bigger_number);
        // now b points inside our stack frame

        recv(fd, b, bigger_number, 0);
        // and now our stack frame is toast

Except for the bit which writes to the freed buffer, I can imagine
that being a fairly common pattern. But I doubt that there are
many modern malloc()s quite as stupid as the one assumed here.

> Perhaps Matthew could point us to a malloc where an area can be just
> marked as free?

You might find a malloc() which keeps the free list fairly dense at
the front of the list. That could reduce cache footprint and save
dirtying free()d pages.

Matthew.