Re[2]: Preventing exploitation with rebasing

[dullien () gmx de]

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