|
Authored by: Anonymous on Saturday, January 26 2013 @ 12:30 AM EST |
It will work for some implementations of malloc.
Some versions of malloc work by knowing where the end of the
program is, and then asking the kernel to add a bit to the
top of the program when it's needed. When the top chunks of
allocated memory are no longer needed, malloc hands them
back to the kernel. Read the man pages for rbrk/sbrk to
understand how this works.
Malloc can keep adding a bit until they hit the stack, which
will be more or less known on some systems.
So the way this works is to call malloc a whole bunch of
times for relatively small chunks. After whaterver
fragmentation that already exists is filled up, malloc will
start returning sequential blocks of memory.
So when you run out of memory, if you start freeing the last
chunks of memory allocated, they will be right below the
stack. So you have a pretty good idea of where they are.
Windows is especially vulnerable here since the stack size
and location is specified in the executable, but I think
most operating systems could still be exploited in practice.
Then if you load a DLL, there is really only one place it
can go. So you know where that is.
If you use a version of malloc based on mmap, then mmap
should return memory from randomized spots in the address
space. So when you run out of memory, there is no way of
knowing where the last few chunks came from. This will
defeat the attack. It also makes it easier to load dll's
since they can be intermingled with heap memory without
trouble.[ Reply to This | Parent | # ]
|
|
|
|
|