Re: [VULN-DEV] Future of buffer overflows ?

[Thomas Dullien <dullien () gmx de>]

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