Onderwerp: Preventing exploitation with rebasing

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

I've received a great number of mails about rebasing a system. So I'll
sumarise here

> This won't protect against heap overflows etc.

Agreed. The suggestion I was making was that exploits that rely on a
specific instruction such as "jmp esp" being at a specific address can be
defeated or slowed down by this.

>You can brute force the address space.

Yes - you can - IF the server stays up. In many cases it does not. In those
cases where the server does stay up at least you _have_ to brute force. It
means that you haven't compromised my server straight away. In the interim
of the exploit starting the attack on the server and the server being
compromised I'd hope that my _other_ defences such as IDS/IPS will notice
that something is awry.

> It's better to patch

Of course it is. (If you do rebase a system though you'll need to re-rebase
it after applying patches.)

>or mark the stack as non-executable

Sure. But in the absence of this rebasing can help protect.

> Most exe's don't have a .reloc section and can't be rebased.
Agreed. I was in error and forgot when writing the mail. That said even if
the exe can't be rebased then default Image Base is 0x00400000. _If_ there
was a suitable instruction in the exe image - one that will get you back to
the actual code - then this address has a NULL in it. Many vulnerabilities
require the arbitrary code to go after the saved return address as
everything above gets munged. So the possibility of exploitation is
reduced - note reduced - not negated.[Of course - in the case of unicode
overflows the NULL is not an problem]

What determines whether this is a reasonable protection method/step to take
is the cost versus likelihood of attack.

It's easy to rebase a system so the cost is low. As most Windows exploits
are simple affairs the likelihood of attack is fairly high.

Those that rebase their system will be vulnerable to c. 30-40% of exploits.
Those that don't will be vulnerable to 100%.

What I'm trying to say is that, "If my system has to be/or is going to be
vulnerable to a vulnerability - I want to make sure that it's going to be a
better than average exploit that suceeds in gaining control."

Security is about putting as many hurdles in front of an attacker as
possible. The more hurdles the less likely they are to break in. I'm not
forcing anyone to adopt this as a "hurdle" to add. I put it forward simply
as another line of defence that people may choose to do if they wish.

Take it or leave it.

Cheers,
David Litchfield

--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

hi,

On Mon, Feb 03, 2003 at 09:08:35PM -0800, 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).
>=20
> 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 eve=
ry
> 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.

well, calling return-into-stack technique as major reason why exploiting the
bug is possible is quite misguiding, it's just technique (used by .ida worms
first, imho) to make things work good, but well, in case of slammer this is
right.

> This address is in a dynamic link library (DLL) , sqlsort.dll which has an
> "image base" of 0x42AE0000.
>=20
> 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 fai=
led
> to infect this particular box; the "jmp esp" instruction that should've b=
een
> at 0x42B0C9DC on this system would be found at 0x42B1C9DC so the worm wou=
ld
> 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.

i would like to point out that in case of forking and/or restarting services
bruteforcing the shellcode address on stack/heap would work good too.

even in case of one-shot exploitation, if attacker can stuff stack/heap with
lot of data, and then simply use NOPs to hit his shellcode.

> 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 orig=
in,
> 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 spre=
ad
> by mosquitoes. Whilst someone with sickle cell trait can still catch
> malaria, the gene mutates the haemoglobin in their blood in such a way th=
at
> 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.

if were in genetics, wouldn't be better to prove immunity system rather than
implementing a genes for each "malaria", in our case of cyber-lifeforms, for
example non-executable stack/heap ?

> 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.
>=20
> 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.

no. your boxes is immune to exploits using "jmp <controllable stack||heap>"
technique. however, in case of guessing of address - heap/stack position can
be leaked/guessed someway, then you are still vulnerable.

> 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 !=3D0 the base is not valid.
>=20
> 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.
>=20
>=20
> Copyright (C) 1997-2000 Mark Russinovich
> http://www.sysinternals.com
>=20
> -------------------------------------------------------------------------=
---
> --
> WINLOGON.EXE pid: 208
> Command line: winlogon.exe
>=20
> 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
> ..
> ..
>=20
> 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 whate=
ver
> by only a few bytes. For example assume a saved return address is 0x44784=
500
> 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, t=
his
> 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.

sure

> Some ideas to further help prevent exploits from working.
>=20
> Use addresses such as 0x**000000 or 0x00**0000 for the new image base. Wi=
th
> 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)
>=20
> 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.

and heap ?

well, in conclusion - this technique of protecting is quite good one, but
*only* in practice against mass-spreading worms, public exploits, and lazy
microsoft which have quite big ping times to figure out what's really going
on.

> Cheers,
> David Litchfield
> NGSSoftware Ltd
> http://www.ngssoftware.com/
>=20

with regards,
--=20
_ __/|
\'X.X' sd@irc.hysteria.sk / sd@ircnet
=3D(___)=3D http://sd.g-art.nl / sd@hysteria.sk
U


--SUOF0GtieIMvvwua
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iQEXAwUBPj/HkBW3QikEEyWUFAL4rwP9GobXCUZJ5nvdl/eZ3y6CRCREVd4iD4h6
cCGGqfywkI1UptQxkmIrRMVgp8uWaT5dKuFg7MxpirE9xATkSW JvqDWdXB71wzwe
bzPvnFi0V1ndeb08898omM8IzwY0rXI4pYyiZnLSq+A63EoVCi 4ptFnsnVintJ4D
vmVsx5xviaYD/iHhRHKMfTS1oCgO93UJfSdJFtGzuUza51k+XCXfcv/tcdeuPBoe
WMinp4H70ciM/qyQQkyjorPXqbBydJgsqlRh88ir8AedIFYN2MmEAD7K8xBh3TZ F
tI7UFNet1lOiooZr+h7Xk0spt3gvJbIsUf8Owikzknsf+ixCWS b8RU4g
=etQh
-----END PGP SIGNATURE-----

--SUOF0GtieIMvvwua--

> 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.


Similar idea, applied to the location of stack, was implemented in OpenBSD.
This is from OpenBSD CVS (August 2001):

"Add a possibility to add a random offset to the stack on exec. This makes
it slightly harder to write generic buffer overflows. This doesn't really
give any real security, but it raises the bar for script-kiddies and it's
really cheap.

The range of the random offsets is controlled by the sysctl
kern.stackgap_random (must be a power of 2)."


http://www.openbsd.org/cgi-bin/cvswe...1=1.54&r2=1.55

Hi David,

> [...] 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.

The idea is very elegant (in fact we have planned to include a variation of
it in an upcoming product), but unfortunately it will not work very well
with system DLLs. Many Windows system DLLs can't be safely rebased. Although
they include relocation information, they make assumptions about where in
memory they (or other system DLLs) will be loaded. Essentially, if you
rebase some of the system DLLs, your system will become unstable or will
fail to start. Also, many exes do not include relocation information at all
(since exes are loaded first they are not supposed to be relocated in normal
operation). You will not be able to rebase them either.

Best regards,

Torbjörn Hovmark
______________________________________
Abtrusion Security AB
- next generation intrusion protection
http://www.abtrusion.com