Re[2]: Preventing exploitation with rebasing

From: dullien@gmx.de
Date: 02/05/03

  • Next message: Anonymous: "RE: Preventing exploitation with rebasing"
    Date: Wed, 5 Feb 2003 18:02:05 +0100
    From: dullien@gmx.de
    To: "David Litchfield" <david@ngssoftware.com>
    
    

    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



    Relevant Pages

    • Preventing exploitation with rebasing
      ... Every image file, DLL or executable, has an "Image Base" and this base is ... being "vulnerable" to the buffer overflow vulnerability would have been ... But then another worm uses another DLL so I rebase that one, ...
      (Bugtraq)
    • Re: Preventing exploitation with rebasing
      ... > Every image file, DLL or executable, has an "Image Base" and this base is ... > being "vulnerable" to the buffer overflow vulnerability would have been ... But then another worm uses another DLL so I rebase that one, ...
      (Bugtraq)
    • RE: Preventing exploitation with rebasing
      ... Also remember to rebase dll data sections. ... > Every image file, DLL or executable, has an "Image Base" and this base is ... > being "vulnerable" to the buffer overflow vulnerability would have been ...
      (Bugtraq)
    • Re: Preventing exploitation with rebasing
      ... In fact if I rebase every DLL on my ... the main EXE (which is always mapped at 0x00400000 ... If all the DLLs are ... Of course this requires that the server stays up. ...
      (Bugtraq)