Vulnerability Development mailing list archives
Re: Future of buffer overflows ?
From: "Granquist, Lamont" <lamont () ICOPYRIGHT COM>
Date: Sat, 4 Nov 2000 18:32:54 -0800
On Fri, 3 Nov 2000, Thomas Dullien wrote:
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.
Well, PaX needs to also include Solar's patch to map libc to have a NULL byte, otherwise its entirely trivial to return-into-libc-system(). Without Solar's libc patch, non-exec stacks are barely a roadbump. Assuming they've done that it gets a little bit more interesting. If you've got strcpy() in the PLT though you just strcpy() a NULL byte into your stack and then use that to return-into-libc-system(). And you can of course substitute anything for strcpy() that will let you plop a zero down on your stack in the middle of your buffer overflow. I can't imagine a real program that didn't have something useful in the PLT or somewhere in its own code that you could use to drop a NULL onto the stack. Lots of programs have really useful things like system() or exec() in the PLT as well, which makes things really easy. Of course, in the face of an unknown kernel version and an unknown libc version crafting a remote buffer overflow becomes problematic. But against a known version of the kernel and a known version of libc the offsets should all be the same AFAIK. So, dropping a patch like this into the RH7.x kernel would buy you nothing against scriptkiddies 0wning default RH7.x installs. OTOH, a stackguard distro with the latest patches and the openwall kernel tweaked to move libc to a custom location could be freaking difficult to break into. Of course if they come in through a CGI script and get a shell, then they can easily figure out the offsets and break root, no matter how non-exec'd your kernel is. Is it security or not? Probably depends on your installation.
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)