Onderwerp: Re[2]: Preventing exploitation with rebasing

Hey David,

(first off, Secfocus seems to have you on "fast moderator approval"
track, I see your reply's before mine show up on BQ

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

Yes. But bar raising and "almost invulnerable" are two seriously
different things. Wearing a bulletproof helmet protects me against
gunshot wounds to the head, but doesn't make me "almost invulnerable
to any given bullet, past, present, or future".

Thing is, if people start rebasing, exploit writers will start
rewriting, and nothing has changed.

>> Rebasing everything is something you're not very likely to achieve. Hardly
DL> 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)

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

Sorry, I shoddily phrased the above: EXE files are usually generated
by the compiler without relocation information, and usually assigned
0x00400000 as base by the compiler, which can be easily overriden.

This does not change the fact that EXE's generated without relocation
info cannot be rebased (if you tried it and you work you've been
_very_ lucky, and probably made the program _very_ unstable)

Now, winlogon, services, lsass ... they all have no reloc info and
cannot be rebased.

If you check through your hard disk, you'll find that rebasable .EXE's
are exceptions in a large sea of nonrebasable EXE's -- so in most
cases you will be stuck with keeping the EXE at it's predefined base
address (which is known to the attacker).

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

Hrm. Situations that _require_ arbitrary code to go after the saved
return address are rather few -- I am not sure if I've ever
encountered one. There's pretty much always a way around this.

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

Yes. What's the percentage of stack smashes vs heap corruptions ?
Experience has shown (in the *nix world) that heap corruptions don't
surface until the stack smashes have run out, and I'd assume/guess
that the ration is somewhere around 1:2. Perhabs worse.

>> c) Will be suspectible to brute-force attacks on your address space
>> (which cannot be more complex than 2^15 ... hardly a "hard"
>> task)
DL> Of course this requires that the server stays up. In the case of SQL Server,
DL> and many other issues, it would not - so you get one chance.

Agreed. One-shot-exploits which are stacksmashes are very hard in a
_completely_ rebased address space. See above why the address space is
rarely every completely rebased.

DL> Again, I'll reiterate - this is not a full proof method. Here it is in black
DL> and white.
DL> If I don't rebase my system I'll be vulnerable to every basic exploit.
DL> If I do rebase my system I won't be vulnerable to every basic exploit.
DL> Personally I prefer the later option.

No doubt. But as full rebasing is rarely feasible, _and_ will not
protect me from the majority of all bugs, it's usefulness under NT is
.... doubtful. You can make a small subset of exploits pretty hard (IF
the .EXE contains relocation info). But that's all there is to it.

Cheers,
Thomas

> -----Original Message-----
> From: David Litchfield [mailto:david@ngssoftware.com]
> Sent: Tuesday, February 04, 2003 12:09 AM
> To: bugtraq@securityfocus.com; ntbugtraq@listserv.ntbugtraq.com;
> vulnwatch@vulnwatch.org
> Subject: Preventing exploitation with rebasing
>

> So how easy is it to rebase DLLs and executables? Very. Microsoft have
> provided a function to do this, ReBaseImage(), exported by
> imagehlp.dll. If
> you rebase an image the new base must be on a 64K boundary -
> i.e. if the
> image base mod 64000 !=0 the base is not valid.
>

There is a tool called "ReBase" shipped with Visual C++ and Visual C++.NET.

<http://msdn.microsoft.com/library/de...-us/tools/perf
util_2z39.asp>

<quote>
Rebase is a command-line tool that you can use to specify the base addresses
for the DLLs that your application uses.
</quote>

<quote>
Alternatively, you can use the ReBaseImage function.
</quote>

> 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

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