[17449] in bugtraq
Re: Future of buffer overflows ?
daemon@ATHENA.MIT.EDU (Michal Zalewski)
Wed Nov 1 21:58:16 2000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.4.21.0010301946430.18493-100000@dione.ids.pl>
Date: Mon, 30 Oct 2000 19:52:17 +0100
Reply-To: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
From: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
X-To: Thomas Dullien <Dullien@GMX.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <3170.972916784@www12.gmx.net>
On Mon, 30 Oct 2000, Thomas Dullien wrote:
> 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 ?
Code is always executable. Traditional function calling convention uses
stack to pass function parameters. Stack overwrite vulnerabilities are not
dead as long as stack is used to store local buffer variables and there is
no range checking. The same applies to heap buffer overflows. There is no
need to execute code passed on stack. Just it is the simpliest and most
accurate way. All techniques - libsafe, StackGuard, PaX, etc - are still
only a workarounds, not a solutions.
You might want to take a look at http://agt.buka.org - our almost
completed new approach to programming in untrusted, distributed
environments. Code will be released in a few days, and right now you might
want to read the concepts :)
> So it raises the bar for us all :) but just might make writing
> exploits an interesting business again.
:) Thanks god.
_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
