Re: libresolv+ bug

[tqbf () rdist org (Thomas Ptacek)]

> It would perhaps be something to consider for hardware designers to
> ensure that any useful sequence of code will contain a 0x00 byte; it
> would make a lot of such overruns harder to exploit, since most of
> these overruns do not permit installing any code that contains a 0x00
> byte.  (Which is one reason they're so bad on Intel hardware, it being

Not to be argumentative...

This is completely untrue. In fact, every single "buffer overflow exploit"
I've read thus far has (successfully) coped with the ASCIIZ NULL byte
problem. A system call on Intel BSD operating systems requires a long call
to (long)0:(word)7, which encodes into 0x9a 0x00 0x00 0x00 0x00 0x07.

The authors of the splitvt exploit (which is seminal work as far as buffer
overflow exploits go, and everyone should read it - everyone who's writing
buffer overflows is basing at least some of their code off of it) dealt
with the null byte problem the same way 8086 demo coders did - you can
usefully create the equivalent of a NULL simply by XOR'ing a register
against itself, and then using that (now cleared out register) to bash
NULLs into memory where needed.

Brian Mitchell's BSDI rdist exploit uses the same trick to bash the NULL's
out of the lcall operation, as well as providing NULL termination in 3
different memory areas.

People playing with Sun overflows are doing the exact same thing (since
it turns out that lots more instructions for SPARCs require NULL bytes),
so quite a bit of bit-manipulation goes on to massage the instructions
ahead of the IP into the appropriate code.

So, basically, you're saying that chip designers should make sure that
not only does every OS-meaningful opcode (transfers of control, primarily,
as well as memory addressing) contain a NULL, but also absolutely every
opcode that manipulates bits as well (thus preventing people from loading
opcodes ahead of them into registers, bashing them about with logical
operators, and sticking the 'fixed' opcodes back into memory).

I'm sure you were probably being facetious.

Which is neither here nor there (somewhere in between, I think), except
that it's fairly good reasoning for why kludges like "make sure they need
to use NULLs, because NULLs are a bitch to deal with in buffer overflows!"
aren't really buying you security.

If you'd like to avoid the "conventional" stack overflow tactics, you can
do so without hardware modification (<stifling giggles>) simply by keeping
as many "buffers" as you can in dynamically allocated memory (malloc char
stars instead of declaring character arrays, etc, etc). Beyond subversions
that are made possible by manipulating the program's data (what filename
is that SUID program writing to? What UID did getuid() return? etc...),
nobody's talking about a way to exploit dynamically allocated memory to
cause inappropriate transfers of control.

But, as we all know, that's not a particularly effective solution to the
problem. The real problems, as I'm sure you'll agree, der Mouse, are that
SUID programs aren't being written carefully enough, library routines that
are potentially depended on by SUID programs aren't written with those
security issues in mind, and, in general, most Unix OS's give
"priveledged" programs that need to do one or two specific things far, far
too much power.

Or, more succinctly, all the hardware opcode-munging and internal bounds
checking and runtime sanity checks in the world aren't going to save an
SUID program from the next 2049 race conditions we'll find in it after
fixing buffer overflows.

Perhaps a better "fix" to discuss would be to find out what problematic
SUID programs need their SUID permissions for, and discuss a way around
that. I, for one, would be really happy to see the next discussion about
the next SUID hole be accompanied with a discussion of "how can we rewrite
this program so it never needs to run as root?".

-----------------------------------------------------------------------------
Thomas Ptacek at The rdist Organization,
Chicagoland's only kung-fu guerilla terrorist computer security organization.
------------------------------------------------[ tqbf () rdist org ]-----------
"If you're so special, why aren't you dead?"