Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Subject: Future of buffer overflows ?
From: Thomas Dullien (DullienGMX.NET)
Date: Mon Oct 30 2000 - 08:39:44 CST
- Next message: HT Regz: "Re: Minor bug in Pagelog.cgi"
- Previous message: Casper Dik: "Re: announcing PaX"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
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
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.
-- Sent through GMX FreeMail - http://www.gmx.net