Vulnerability Development mailing list archives
Re: Future of buffer overflows ?
From: "Bluefish (P.Magnusson)" <11a () GMX NET>
Date: Sat, 4 Nov 2000 06:03:57 +0100
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.This is not a new concept. It's been out there for a while now...
Ah; yes. Only intel messed up the security paging features, writing==execute on intel x86. However, assuming the following: - a processor without this or similar flaws becomes mainstream - compilers are introduced which makes fully use of this; - constants Read Only, No Exec - stack & global variables is Writeable, No Exec - code is Read Only Then we have a quite different game to play: aribitery code cannot be into a program. This renders are number of overflows, formatation bugs and future - today unknown - standard techniques to be crippled. Not bullet proof, as executation can be tampered with, but many applications will be extremly hard to exploit when you can't introduce new code to it. Your last example was quite interesting ; on unprotected stacks it clearly offers very long exploits to run small overflows. However, although technically interesting, the memcpy() trick is merely an improvement of older techniqes; it relays on something to be both executable and writable. With a decent processor and a correct os/compiler design that simply won't be the case. Now, that probably sounded a bit more sceptical than I really am. Because I kind of lack faith in that we will live in a perfect world within forseeable future, so even if your attack theoreticly is defeated it will work in real world for a long, long time ;) ps. Anyone who knows if this is fixed in IA64 or AMD's X86-64 architectures? And if so, how many of the OSes/compilers for these architectures actually makes use of it, and if so, fully? ps. I'm aware that there is a none-exec stack patch to x86 Linux. It is however not included in the official kernel because it uses memory segmentation instead of paging, which is considered uggly. ..:::::::::::::::::::::::::::::::::::::::::::::::::.. http://www.11a.nu || http://bluefish.11a.nu eleventh alliance development & security team http://www.eff.org/cafe
Current thread:
- Re: Future of buffer overflows ? Thomas Dullien (Nov 03)
- Re: Future of buffer overflows ? Crispin Cowan (Nov 04)
- Re: Future of buffer overflows ? Michael H. Warfield (Nov 05)
- Re: Future of buffer overflows ? Bluefish (P.Magnusson) (Nov 06)
- Re: Future of buffer overflows ? Granquist, Lamont (Nov 06)
- <Possible follow-ups>
- Re: Future of buffer overflows ? Bluefish (P.Magnusson) (Nov 05)
- Re: Future of buffer overflows ? Thomas Dullien (Nov 05)
- Re: Future of buffer overflows ? Bluefish (P.Magnusson) (Nov 09)
- Re: Future of buffer overflows ? David Wagner (Nov 10)