Hey David, all,

the method described in this paper has been previously described &
implemented (in a much more thought-out manner) for Linux-based systems as
PaX, to be found under pageexec.virtualave.net.

DL> to infect this particular box; the "jmp esp" instruction that should've been
DL> at 0x42B0C9DC on this system would be found at 0x42B1C9DC so the worm would
DL> have been off target. The SQL Server running on this system, whilst still
DL> being "vulnerable" to the buffer overflow vulnerability would have been
DL> invulnerable to this worm. Sure - the SQL Server may have crashed - but it
DL> would not have been compromised.

DL> Server install on the planet. In fact if I rebase every DLL on my system and
DL> every executable then I can make my box almost invulnerable to a given
DL> exploit, past, present or future. It's not that my box is invulnerable to a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Bullshit. I am willing to bet that most heap overflows will be
exploitable even in a fully rebased address space. I don't need to
know a "jmp ebx"-address, I can _write_ a "jmp ebx" wherever I
want.

DL> buffer overflow vulnerability - it's just invulnerable to the exploits for
DL> it. To gain control of a system protected in such a way
DL> would require that the author of the exploit know the location of loaded
DL> DLLs.

Rebasing everything is something you're not very likely to achieve. Hardly any
commercial software has executables which still contain valid
relocation information -- which means that you can rebase all DLL's as
much as you want, the main EXE (which is always mapped at 0x00400000
and cannot be remapped) will be present & can be used for
exploitation. Unless you rebase the complete address space you remain
vulnerable. Furthermore, rebasing might not be sufficient, as there's
less than 32k different bases -- if the service restarts cleanly brute
force is definitely an option. So you need full randomization.

Heap corruptions allow an attacker to write arbitrary data to
arbitrary locations -- so he can patch his own "jmp ebx" or whatever
to whereever he wishes. Unless you implement something PaX-like for
writable/executable pages, you're still vulnerable. And the majority
of all buffer overruns _are_ heap corruptions.

Oh, and there's always the static mapping of the TEB's under Windows.

So the solution you're proposing
a) Will only work against a small subset of all
closed-source-applications (those with relocatable main .exe)
b) Will even then only protect you against vanilla stack smashes, and offer 0
protection against heap corruptions or format string bugs
c) Will be suspectible to brute-force attacks on your address space
(which cannot be more complex than 2^15 ... hardly a "hard"
task)

There's many more weaknesses to what you propose.

Cheers,
Thomas

[ reply ]