Future of buffer overflows ?

[Thomas Dullien <Dullien () GMX NET>]

Well, I assume you all have read the PaX paper at pageexec.virtualave.net.
So it is possible to have readable, non-executable memory pages, at a
not too bad performance hit of up to 10%. This is very cool. The
traditional
way of exploiting buffer overruns and format string vulnerabilities are
pretty much non-functional if the OS kernel can ensure no writable page
can be executed.

Does this mean buffer overflows and format string vulnerabilities are dead
?

On systems that actually implement this kind of protection, they are
going to have a lot less importance than before. Cutting & pasting
shellcode
just won't do it any more.

So what can you still do with a buffer overrun ?
This depends largely on the particular situation and has to be decided on
a case-by-case basis, but generally a stack overflow can still be used
to issue one libc/msvcrt call with arbitrary arguments as long as they
do not include a NULL byte as args. Now with a single system() or exec()
you can do a few funky things, and even memcpy() is a very cool thing
to execute. If you manage to keep the stack in a consistent state and
you don't crash the application, you might even be able to do this several
times in a row.
Format string vulnerabilities still allow you to write to any location in
memory. Patching internal variables and overwriting vtable pointers is
a funny thing to do.

So to wrap it up: The PaX project is IMO awesome. But even if buffer over-
runs and format string vulnerabilities loose the instant remote root shell
danger, they can still allow a skilled attacker to do things he's not
supposed to. And its only up to the creativity of the attacker what he
does. So it raises the bar for us all :) but just might make writing
exploits an interesting business again.

Cheers,
Thomas


--
Sent through GMX FreeMail - http://www.gmx.net