Vulnerability Development mailing list archives
Re: Future of buffer overflows ?
From: Thomas Dullien <dullien () gmx de>
Date: Fri, 3 Nov 2000 13:11:34 +0100
On Wed, 1 Nov 2000 15:21:10 -0300, Gerardo Richarte wrote: Hey Gerardo,
This is not a new concept. It's been out there for a while now...
Ermm.. no ;> Non-exec heap & stack pages are new to the x86 platform at least. They exist on a few other CPUs, but on x86 they are a 'hack' ;>
[code] &memcpy &place &place &buffer what? translated into: memcpy(&buffer,&place) jmp &place ; place() memcpy() copies from buffer to a useful place where you can write and execute (is there a place like this?), then, it returns
This is the crucial point :) A well-armored kernel as the PaX team wants to implement will not allow any writable pages to be executable. The memcpy() stuff won't work.
The second option... let's call it "pop&ret" ok, this is from the top of my head, this code is not tested, it's not bullet proof, but the method has been tested (and used) successfully in our labs...
Well, that is one of the major problems :) While the methods you describe are all nice & dandy in a lab environment, the don't really work 'in-the-wild'. In order to write a working pop&ret program, you need to _guess_ quite a few offsets either in libc or in kernel32.dll. This makes the exploit highly unreliable. Now, while it is still possible to write a working exploit in your lab, the probability that you will be able to remotely compromise a well-secured and firewalled host rapidly diminishes. I am not saying this is a bad thing ;> but the usability of buffer overflows rapidly decreases if you first shoot down the buggy daemon a few times triggering all alarms along the way before you actually get to do something. Actually, I do think that non-exec pages increase security. Many of the more obscure buffer overflows (with filtered chars and the like) will get even harder (if not impossible) to exploit. If libc is mapped at an address with a NULL byte you cannot just return into it with any arguments either. While Solars patch still allowed data section returns, the PaX even prevents that. Yes, it does not fix the problem of buffer overflows completely, but it is IMO a good step. And I didn't claim that b/os were dead ;> I just said the bar is being raised significantly. Cheers, Thomas
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)