Bugtraq mailing list archives
Future of buffer overflows ?
From: Thomas Dullien <Dullien () GMX NET>
Date: Mon, 30 Oct 2000 15:39:44 +0100
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
Current thread:
- Future of buffer overflows ? Thomas Dullien (Oct 31)