> 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.
>

Keyword in my preceding statement : "almost" - as in "almost invulnerable".
The context of the discussion was a method to defeat exploits that use fixed
locations. The statement was meant in that context - I thought that much was
obvious. I also end the mail by saying this method is NOT full proof and
they are ways of defeating it. Rebasing will help cut out many of the
exploits written for a vulnerability - it raises the bar and requires a more
advanced exploit.

> 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)

This is simply not true. There are many exe image files with a base of
0x01000000
e.g. winlogon, services, lsass, etc, etc.

> 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)

Could be small or large - exact numbers would be useful. If all the DLLs are
rebased then you still need to find a suitable instruction in the exe. Added
to this - the common default base of 0x00400000 will mean there's a NULL in
the address cutting out a great deal of vulnerabilities that require
abritray code to go after the saved return address.

> b) Will even then only protect you against vanilla stack smashes, and
offer 0
> protection against heap corruptions or format string bugs

Agreed. This method is to prevent those exploits that require an address to
contain a specific instruction.

> c) Will be suspectible to brute-force attacks on your address space
> (which cannot be more complex than 2^15 ... hardly a "hard"
> task)

Of course this requires that the server stays up. In the case of SQL Server,
and many other issues, it would not - so you get one chance.

>
> There's many more weaknesses to what you propose.

Again, I'll reiterate - this is not a full proof method. Here it is in black
and white.

If I don't rebase my system I'll be vulnerable to every basic exploit.
If I do rebase my system I won't be vulnerable to every basic exploit.

Personally I prefer the later option.

Cheers,
David

[ reply ]