Re: [VulnDiscuss] Re: Preventing exploitation with rebasing

[Halvar Flake]

Hey David,

DL> Assuming the server did stay up, though. You've got to go through 0x7FFFFFFF
DL> addresses looking for your code or something that will get you back to your
DL> code. There'll be maybe 50 addresses with "jmp esp" - or whatever
DL> instruction you're looking for - giving you a 1 in 42949672 chance or so.
DL> Brute forcing is not reliable therefore. With all those attempts - someone's
DL> going to notice something going on - or so one would hope, anyway.

Your math is broken :-) DLL's are (as you stated) based mod 64k, so
there's only 0x80000000 / 64k - 1 different addresses on which a DLL can
start. That's less than 32k, and your chance is 1 in 32768. On
average, you get a hit after 16384 tries. Oh, btw, this method could
be optimized as you can be pretty sure that large DLL's aren't mapped
closely underneath 0x80000000.

How do you deal with EXE's that have been stripped of relocation
information ? (simple answer, not at all)

Cheers,
Halvar

[Jason Coombs]

Three different rebasing scenarios:

(1) other people's compiled code
(2) other people's source code
(3) your own code

Points:

A. There are better things to do in the case of (2) and (3) than rebase the
binary.

B. In the case of (1) rebasing offers some value in certain circumstances,
particularly if you have access to the source (2) -- in which case point A
applies and you shouldn't bother with rebasing somebody else's binary.
Rebase the entire build, and throw in a boatload of NOPs and other
spaghetti. The less predictable your binaries are from the perspective of a
remote attacker, the better.

C. Remember the threat: uncontrolled/arbitrary remote procedure calls. Don't
let them happen in the first place. Authenticate every caller. Filter and
block all anonymous callers. Stop the bits from entering your box (or
process space) in the first place.

D. Don't allow compiled code to execute on your box unless it has been
authorized to execute in advance based on its hash code.

E. If code is vulnerable, don't use it.

Jason Coombs
jasonc@science.org

[Charlie Root]

Dear David !

With all the respect... I think your ideea is a BAD one ! Why ? Well...
It might be verry efective if one to... mhm... 100 persons would aply
this technique. That's because hackers/worms wouldn't mind loosing a few
servers if they got the rest of the world. But if this technique would
became a standard then the worm-industry (if there is such a thing)
would also evolve... making it brute-force the addreses. I admit that
brute-forcing would slow down the worm/hacker/whatever... but this is no
way of looking at the security. This is like protecting a house/store by
putting 15 doors that all could be easily broken... Of course there is a
chance that a thief trying to break in would get bored breaking door
after door... but if he's really determined... Well... I guess I made my
point.

Why was slammer so successfull... Well... Here's my oppinion: Sysadmins
experienced in windows usually have little firewalling skills. That's
probably because there is no powerfull firewalling tool like ipfw or
ipchains on windows. If all the SQL ports would have been firewalled the
worm would probably wouldn't have caused any harm.

Rebasing might be usefull up to some point. But it contains a "mental"
vulnerability. If one would apply this technique he would probably think
he is safe and neglect updating his security. Oh, and one more thing...
I'm not sure about this since I have little expirience in windows:
security-patches don't relly on the same "genetic code" as exploits ? If
one would rebase his entire system would he still be able to properly
apply security patches ?

best regards
Charlie Root

David Litchfield wrote:

>Defeating Exploits
>**************
>The ideas in this "paper" present a method for defeating exploits; not the
>actual vulnerability. Before getting to the details let's consider slammer
>(again).
>
>What made slammer so successful?
>The overriding factor that made slammer so successful was it's ability to
>spread. What made it's spread a foregone conclusion was the fact that every
>vulnerable SQL Server/MSDE had a "jmp esp" instruction at address
>0x42B0C9DC. This was the address that was used to gain control of the SQL
>Server's path of execution to a point where the worm's payload, the
>"arbitrary code", would be executed.
>
>This address is in a dynamic link library (DLL) , sqlsort.dll which has an
>"image base" of 0x42AE0000.
>
>Every image file, DLL or executable, has an "Image Base" and this base is
>the preferred location where the file should be loaded into memory by the
>Windows Loader. [I don't want to digress, here, as to what happens if
>there's a conflict. See the references at the end.] Now if this Image Base
>on one particular system had been 0x42AF0000 then the worm would have failed
>to infect this particular box; the "jmp esp" instruction that should've been
>at 0x42B0C9DC on this system would be found at 0x42B1C9DC so the worm would
>have been off target. The SQL Server running on this system, whilst still
>being "vulnerable" to the buffer overflow vulnerability would have been
>invulnerable to this worm. Sure - the SQL Server may have crashed - but it
>would not have been compromised.
>
>It's like sickle cell. Someone born with the gene that causes sickle cell
>anaemia, a blood disorder that affects many people of a West African origin,
>or carriers of the gene, sickle cell trait, do not suffer from the ill
>affects of malaria, a disease caused by a parasite and most commonly spread
>by mosquitoes. Whilst someone with sickle cell trait can still catch
>malaria, the gene mutates the haemoglobin in their blood in such a way that
>they are invulnerable to the debilitating side effects and syptoms of the
>disease such as mental confusion, coma and death. There is an obvious
>evolutionary advantage to sickle cell trait; remember that the evolution of
>the species cares not about how long a person lives, only that they live
>long enough to pass on their genes. (Those with anaemia may suffer from
>crises, periods of acute pain so the trade off is somewhat questionable.)
>
>In areas where malaria is a common cause of death, being a carrier of the
>sick cell gene can help ensure that this person lives long enough to have
>progeny. This is Darwinian natural selection in progress.
>
>Rebasing
>*******
>The problem with operating systems is that they all have pretty much the
>same "genetic code" which makes each and every one of them vulnerable to a
>new exploit. So we need to make them different and this can be achieved
>through rebasing. Rebasing is the process of changing the Image Base of an
>image file. By doing this the DLL/EXE is loaded into a different location in
>the virtual address space.
>
>Going back to Slammer, had I have rebased sqlsort.dll giving it a new base
>of 0x41410000 my box would have been invulnerable to the worm. If another
>worm were written, though, that used an address that contained a "jmp esp"
>instruction in kernel32.dll then I would be vulnerable. So I rebase
>kernel32.dll. But then another worm uses another DLL so I rebase that one,
>too. Eventually I've rebased all of the DLLs used by SQL Server mutating
>it's "genetic code", making it considerably different to any other SQL
>Server install on the planet. In fact if I rebase every DLL on my system and
>every executable then I can make my box almost invulnerable to a given
>exploit, past, present or future. It's not that my box is invulnerable to a
>buffer overflow vulnerability - it's just invulnerable to the exploits for
>it. To gain control of a system protected in such a way
>would require that the author of the exploit know the location of loaded
>DLLs.
>
>So how easy is it to rebase DLLs and executables? Very. Microsoft have
>provided a function to do this, ReBaseImage(), exported by imagehlp.dll. If
>you rebase an image the new base must be on a 64K boundary - i.e. if the
>image base mod 64000 !=0 the base is not valid.
>
>The only other problem is Windows File Protection. Once you've rebased a
>copy of the DLL you need to copy the new DLL over the old one but Windows
>File Protection won't allow you to do this. To get around the problem use
>the MoveFileEx and specifying the MOVEFILE_DELAY_UNTIL_REBOOT flag. Doing
>this will add a registry value, "PendingFileRenameOperations" to
>HKLM\System\CurrentControlSet\Control\Session Manager\. You then need to add
>another DWORD value "AllowProtectedRenames" and set it to 1. Then restart
>the system. On reboot the new DLLs, with their new image bases, will be
>loaded. For example - here is sample output of listdlls after kernel32.dll
>and ws2_32.dll have been rebased.
>
>
>Copyright (C) 1997-2000 Mark Russinovich
>http://www.sysinternals.com
>
>----------------------------------------------------------------------------
>--
>WINLOGON.EXE pid: 208
>Command line: winlogon.exe
>
> Base Size Version Path
> 0x01000000 0x2e000 \??\C:\WINNT\system32\winlogon.exe
> 0x77f80000 0x7b000 5.00.2195.5400 C:\WINNT\System32\ntdll.dll
> 0x78000000 0x46000 6.01.9359.0000 C:\WINNT\system32\MSVCRT.dll
> 0x4a4a0000 0xb1000 5.00.2195.6011 C:\WINNT\system32\KERNEL32.dll
> 0x77db0000 0x5b000 5.00.2195.5992 C:\WINNT\system32\ADVAPI32.dll
> 0x77d30000 0x71000 5.00.2195.5419 C:\WINNT\system32\RPCRT4.dll
> 0x54530000 0x13000 5.00.2195.4874 C:\WINNT\system32\WS2_32.dll
>..
>..
>
>Now all the way through this I've been saying things like "almost
>invulnerable" etc. Here's the reason. For some vulnerabilities it may be
>sufficient to overwrite a saved return address, function pointer or whatever
>by only a few bytes. For example assume a saved return address is 0x44784500
>and at address 0x44784536 is a "jmp ebx" instruction and ebx points to our
>code. Then we only need to overwrite the saved return address by 1 byte -
>with 0x36. So knowledge of the DLL load address is not needed. However, this
>scenario is going to happen so infrequently (if ever) that it does not
>detract from the idea of rebasing your system. There may other ways to
>bypass this method.
>
>Some ideas to further help prevent exploits from working.
>
>Use addresses such as 0x**000000 or 0x00**0000 for the new image base. With
>there being a NULL in much of the image's address space this will help.
>(This of course won't make a difference with unicode overflows)
>
>Ensure at least one (core) DLL has a base of 0x00119400 . This will ensure
>that a common stack location 0x00120000 has been assigned forcing the OS to
>chose another location for the stack. You get the idea.
>
>Feel free to mail me/lists with comments.
>
>Cheers,
>David Litchfield
>NGSSoftware Ltd
>http://www.ngssoftware.com/
>
>
>MSDN Info
>ReBaseImage()
>http://msdn.microsoft.com/library/de...us/debug/base/
>rebaseimage.asp
>MoveFileEx()
>http://msdn.microsoft.com/library/de...us/fileio/base
>/movefileex.asp
>
>
>
>
>
>
>
>
>
>
>

[David Litchfield]

> Dear David !
>
> With all the respect... I think your ideea is a BAD one ! Why ? Well...
> It might be verry efective if one to... mhm... 100 persons would aply
> this technique. That's because hackers/worms wouldn't mind loosing a few
> servers if they got the rest of the world. But if this technique would
> became a standard then the worm-industry (if there is such a thing)
> would also evolve... making it brute-force the addreses.

But often you only get one shot to gain control - if you fail the server
process dies. This happens with the buffer overflow in SQL Server. There is
no exception handling and the process just dies and does not restart.

Assuming the server did stay up, though. You've got to go through 0x7FFFFFFF
addresses looking for your code or something that will get you back to your
code. There'll be maybe 50 addresses with "jmp esp" - or whatever
instruction you're looking for - giving you a 1 in 42949672 chance or so.
Brute forcing is not reliable therefore. With all those attempts - someone's
going to notice something going on - or so one would hope, anyway.

>I admit that
> brute-forcing would slow down the worm/hacker/whatever... but this is no
> way of looking at the security.

This is exactly what security is all about. You put as many hurdles in front
of the attacker as you can - the more hurdles the less likely they are to
break in. Rebasing you're system adds another strong hurdle.

>This is like protecting a house/store by
> putting 15 doors that all could be easily broken...

Easily. Okay, if I rebase my system I'll give you 1000 shots to find a "jmp
esp" instruction. Even 2000 or 3000. You'd have to very lucky. I don't think
this is an "easy door" to break down. Sure, it _can_ be broken down but not
with ease.

> Of course there is a
> chance that a thief trying to break in would get bored breaking door
> after door... but if he's really determined... Well... I guess I made my
> point.

Sure - if someone's _really_ determined they'll eventually get in. No-one's
ever claimed anything different.



>
> Why was slammer so successfull... Well... Here's my oppinion: Sysadmins
> experienced in windows usually have little firewalling skills. That's
> probably because there is no powerfull firewalling tool like ipfw or
> ipchains on windows. If all the SQL ports would have been firewalled the
> worm would probably wouldn't have caused any harm.

I think you're wrong here. For a start you've mading a very sweeping
statement - and I'm sure all those Windows admins out there that know
exactly how to configure their firewall will take umbrage with this. Added
to this, a large number of boxes hit by slammer were unprotected MSDE
installs. MSDE is installed in many cases without the knowledge of the user.
They've installed something like the .NET frame work and got MSDE too.


>
> Rebasing might be usefull up to some point. But it contains a "mental"
> vulnerability. If one would apply this technique he would probably think
> he is safe and neglect updating his security.

Again I think you're wrong. Anyone who goes to the length of rebasing their
system "knows" what the threats are - and are not likely to be the kind of
person that relies on one method for security.

>Oh, and one more thing...
> I'm not sure about this since I have little expirience in windows:
> security-patches don't relly on the same "genetic code" as exploits ? If
> one would rebase his entire system would he still be able to properly
> apply security patches ?

You can still patch your system. However, the DLLs will be replaced so you
need to rebase the new DLLs after the patch has been applied.


The idea of rebasing your system is not supposed to be a holistic solution.
It's presented as another method of protecting your system - the more
hurdles the better. I'm not suggesting people rely on this method and
neglect to continue to install patches - the real solution.

Cheers,
David Litchfield

[David S Goldberg]

>>>>> On Tue, 4 Feb 2003 12:08:48 -0800, Brian Hatch <bugtraq@ifokr.org> said:

> I fail to see how adding security that doesn't have a performance
> or stability cost is ever a bad thing.

Agreed. I'm not sure, however, that David's idea doesn't have an
affect on stability. Not the stability of a single server but on an
environment consisting of many servers. I'm not Windows wizard, but
I'll accept from everything I've already read in this thread that
rebasing on a single system will not have a negative impact on it.
However I question how will it scale to several tens of servers, which
is my problem? Is there an easy way to automate it such that it is
done after patch application? Considering how difficult and/or
expensive, take your pick, it is to apply patches in an automated
fashion on Windows systems I suspect not. Moreover, I gather that for
the solution to be effective, each system should be rebased
differently requiring even more planning to get it right even if
automation were easy. This should not be taken as an indictment of
the idea, just asking that when implementing security solutions on
individual machines, the keepers of security should consider the
issues of scale that we sysadmins have to deal with.

Thanks,
--
Dave Goldberg
Associate Department Head, G06A: Advanced Technical Computing Center
The Mitre Corporation \ MS K331 \ 202 Burlington Rd. \ Bedford, MA 01730
dsg@mitre.org \ 781-271-3887

[Alan DeKok]

Much of this thread would disappear if people used hard numbers
instead of opinions.

Brian Hatch <bugtraq@ifokr.org> wrote:
> People keep saying "but it won't stop everything", and that's true.

Exactly. Even DES isn't "perfectly" secure, (i.e. unbreakable). It
*obfuscates* the data, but does not *secure* it. The benefit of DES
is that it has a provable level of obfuscation.

This takes the security versus obscurity argument from the realm of
personal opinion to one of quantitative statements. We should have a
similar goal for this discussion.

> But since when have we turned down a security procedure that is
> not a silver bullet against all evils? I'd love to make it harder
> for worms to attack my systems. I'd love for them to take longer
> to break into the machines down the hall. That means things will
> spread slower, and we can stop the damage quicker. Why is this bad?

It's not. But many people are of the opinion that if a solution
isn't perfect, then it's not "secure". They can then argue that no
security is somehow "better" than an imperfect system.

The problem with those kinds of arguments is that they don't define
the terms used, or what basis is used for the measurements. The
appropriate response is to ignore personal opinions, and instead ask
for clarifications of terms like "useful", or "better".


If attacks can be trivially re-written to work around rebasing,
then it's obvious that rebasing changes the form of the attack, but
not it's potential to succeed.

If rebasing means that attacks have provably a lower probability of
succeeding, then it's obvious that rebasing gives some additional
level of obfuscation, which is generally called "security".


> ... any administrator who has such a "mental" vulnerability probably
> has several other non-rebasing related vulnerabilities on their
> servers anyway. They probably think that a firewall stops all
> attacks, so wouldn't bother rebasing in the first place. This is
> not a satisfying argument against rebasing.

It's an ad-hominem attack with no substance. "Stupid people use
your solution, therefore your solution doesn't help."

Security analysis of algorithms has always been done on the
assumption of perfect implementation. Analysis of implementation or
deployment/configuration bugs is a seperate analysis.

Alan DeKok.