> 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
