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
