Re: Future of buffer overflows ?

["Granquist, Lamont" <lamont () ICOPYRIGHT COM>]

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.