Bugtraq mailing list archives
Re: Preventing exploitation with rebasing
From: "David Litchfield" <david () ngssoftware com>
Date: Tue, 4 Feb 2003 14:52:05 -0800
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
Current thread:
- RE: Preventing exploitation with rebasing Anonymous (Feb 04)
- <Possible follow-ups>
- Preventing exploitation with rebasing David Litchfield (Feb 05)
- Re: Preventing exploitation with rebasing sd (Feb 04)
- Re: Preventing exploitation with rebasing David Litchfield (Feb 04)
- Re: Preventing exploitation with rebasing Eugene Tsyrklevich (Feb 04)
- Re: Preventing exploitation with rebasing Torbjörn Hovmark (Feb 04)
- Re: Preventing exploitation with rebasing dullien (Feb 05)
- Re: Preventing exploitation with rebasing David Litchfield (Feb 04)
- Re[2]: Preventing exploitation with rebasing dullien (Feb 04)
- RE: Preventing exploitation with rebasing Jason Coombs (Feb 04)
- Re: Preventing exploitation with rebasing sd (Feb 04)
- Re: Preventing exploitation with rebasing Charlie Root (Feb 05)
- Re: Preventing exploitation with rebasing David Litchfield (Feb 05)
- Re: [VulnDiscuss] Re: Preventing exploitation with rebasing Halvar Flake (Feb 05)
- Re: Preventing exploitation with rebasing Brian Hatch (Feb 05)
- Re: Preventing exploitation with rebasing Alan DeKok (Feb 05)
- Re: Can't Preventing exploitation with rebasing bugtraq (Feb 05)
- Re[2]: Can't Preventing exploitation with rebasing dullien (Feb 05)
- Observation on randomization/rebiasing... Nicholas Weaver (Feb 05)