Attacking The Windows 7 / 8 Address Space Randomization

[Fi8sVrs]

==================================================

Attacking the Windows 7/8 Address Space Randomization

Copyright © 2013 Kingcope

"Was nicht passt wird passend gemacht"

(English: "If it don't fit, use a bigger hammer.")

German phrase

==================================================

Synopsis - What this text is all about

==================================================

The following text is what looks like an attempt to circumvent windows 7 and

windows 8 memory protections in order to execute arbritrary assembly code.

The presented methods are in particular useful for client-side attacks as used

for example in browser exploits.

The topic that is discussed is a very complex one. At the time I started the

research I thought the idea behind the attack will be applied to real-world

scenarios quick and easy. I had to be convinced by the opposite.

The research was done without knowing much about the real internals of the

windows memory space protection but rather using brute force, trial & failure

in order to achieve what will be presented in the upcoming text. Be warned -

the methods to attack the protection mechanisms hereby presented are not

failsafe and can be improved. Tough in many cases it is possible to

completely bypass Windows 7 and especially Windows 8 ASLR by using the

techniques.

Target Software

==================================================

The used operating systems are Windows 7 and Windows 8, the included PoC code

runs on 32 Bits platforms and exploits Internet Explorer 8. All can be applied

to Internet Explorer 9 with modifications to the PoC code.

For Internet Explorer 10 the memory protection bypass is included and

demonstrated in the PoC. Executing code through return oriented programming

is left as an excercise to the reader.

The PoC makes use of the following vulnerability and therefore for testing the

PoC the patch must not be installed.

MS12-063 Microsoft Internet Explorer execCommand Use-After-Free Vulnerability

This vulnerability is identified as CVE-2012-4969.

It might be possible to use the very same method to exploit other browsers

as other browsers give similar opportunities to the exploit writer. I don't want

to sound crazy but even other Operating Systems might be affected by this, yet

unconfirmed.

Current ways to exploit browsers

==================================================

Today alot of attention is brought to client side exploits especially inside

web browsers. Normally the exploitation is done through the old known method

of spraying the heap. This is done by populating the heap with nopsleds and

actual shellcode. By filling the heap in this way a heap overrun can be used

to rewrite the instruction pointer of the processor to a known heap address

where the shellcode resides quite deterministic.

In order to bypass protections like Data Execution Prevention a ROP chain is

built. There are exploits that install a stack pivot in the first place in

order to exploit a heap overrun as it would be a stack based buffer overrun

using a "return into code" technique. The mentioned modern ways to exploit

heap corruptions are documented very well.

When it comes to Windows 7 and Windows 8 exploitation the exploit writer

will face the obstacle of randomized memory space. There remains the simple

question where do I jump to when having control over the instruction pointer?

It might by possible to leak memory directly from the web browser and use this

information to gain information about the correct offsets and executable code

sections. This requires knowledge about a memory leak bug tough and therefore

is not used alot. Another option is to use old DLLs that do not have their

image bases randomized, for example older Java versions are known to have un-

randomized image bases. This option requires the use of third-party software

that has to be installed.

This text will present a new way to deal with the 'where do i jump when

I have code execution' problem.

Introduction to Windows memory randomization

==================================================

Windows 7 and Windows 8 have a special security relevant protection programmed

in. The so called A.S.L.R or '[A]ddress pace [L]ayout [R]andomization' that

does nothing more than randomize every piece of memory, say its offsets.

For example the program image is randomized, the DLLs the program uses are

randomized too. There is not a single piece of memory from what one could say

after a reboot the data in the memory space will be at the same place as before

the reboot. The addresses even change when a program is restarted.

ActiveX and other useful features

==================================================

Web browser exploits have many advantages to other kinds of exploits.

For example JavaScript code can be executed inside the webbrowser. This is also

the tool that heap spraying makes use of.

Let us have a look at what happens if we load an ActiveX object dynamically

when a web page loads. The ActiveX object we will load is the Windows Media

Player control. This can either be done using JavaScript or plain HTML code.

At the point the ActiveX object is loaded Windows will internally load the

DLLs into memory space if they previously where not inside the programs

memory space. The offset of loading the DLLs in memory space is completely

random. At least it should be. Let us now see how we can manage to put a DLL

into memory space at a fixed address by loading an ActiveX object at runtime.

Exhausting memory space and squeezing DLLs into memory

==================================================

The nuts and bolts of what is presented here is the idea that DLLs are loaded

into memory space if there is memory available, and if there is no memory or

only small amounts of memory available then the DLL will be put into the

remaining memory hole. This sounds simple. And it works, we can load a DLL

into a remaining memory hole. First of all the exploit writer has to code

a javascript routine that does fill memory until the memory boundary is hit

and a javascript exception is raised. When the memory is filled up the installed

javascript exception handler will execute javascript code that frees small

chunks of memory in several steps, each step the javascript code will try to

load an ActiveX object. The result is that the DLL (sometimes there are several

DLLs loaded for an ActiveX object) will be loaded at a predictable address.

This means that now the exploit writer has a predictable address to jump to and

the 'where do i jump when I have code execution' problem is solved.

One problem the method has is that Windows will become unresponsive at the time

memory is exhausted but will resume normal operation after the DLL is loaded

at a fixed address and the memory is freed using the javascript code.

Summary of exploitation stages:

* Fill the heap with random bytes until all memory is used up.

During the heap filling stage Windows might become unresponsive and will relax

soon afterwards

·* Free small heap blocks one by one and try adding a DLL

(for example by using a new ActiveX Object that is loadable without a warning

by Internet Explorer) This DLL (and the DLLs that are loaded from it) will

be squeezed into the remaining memory region (the space that was freed by us

through JavaScript). This address is fixed and predictable for us to jump to

* Free the remaining memory blocks which were allocated before

* Spray the heap using the well known method

* Finally trigger the heap corruption and jump to this fixed DLL base to

execute our code in a ROP manner.

To say it abstract the exploit writer has to be especially careful about the

timing in the JavaScript code and about the memory the exploit routines

themselves take up.

ROP chain and the LoadLibrary API

==================================================

At the time we have loaded the DLL at a predictable address it is possible to

use a ROP chain in order to execute shellcode. The PoC code goes a much simpler

path. It will use a short ROP chain and call the LoadLibrary API that is

contained in the Windows Media Player DLLs. This way another DLL can be fetched

from a WebDAV share and loaded into the Internet Explorer memory space in order

to fully execute arbritrary code.

Windows 8 singularity

==================================================

Testcases have shown that Windows 8 behaves more vulnerable to the method than

Windows 7. In Windows 8 the DLL will be loaded at the very low address 0x10000

and more reliable than in Windows 7. Windows 7 is much more persistant in

loading the DLL at a fixed memory address. The testcases for Windows 7 have

shown that the DLL will be loaded at the predictable address at least 7 out of

10 times of loading the exploit.

The PoC codes

==================================================

There are two different PoCs, one for Windows 7 and one for Windows 8.

The Windows 8 code is a slightly modified version of the Windows 7 code.

Please note that Windows Defender detects the Win8 PoC as being an exploit and

blocks execution. The parts which are detectable by windows defender are

not needed for the A.S.L.R. attack to work. Please disable Windows Defender

if you test the Windows 8 PoC for now.

The Windows 7 PoC is successful if it loads gdiplus.dll at the predictable

fixed offset 0x7F7F0000. If you are lucky and have set up the exploit

appropriately the payload will be executed, which is currently a MessageBox that

pops up.

The Windows 8 PoC is successful if it loads gdiplus.dll at the predictable

fixed offset 0x10000.

Please note that wmp.dll (Windows Media Player DLL) and gdiplus.dll should not

be in the Internet Explorer address space prior to executing the PoC for it

to succeed.

As a final note, the PoC does not depend on the ActiveX control that is added it

can be changed with some effort to load a different DLL.

Here are the mappings I tested when the PoC succeeds:

Windows 7 32-Bit Service Pack 0 & Service Pack 1 across reboots:

Address Size Owner Section Contains Type Access

7F7F0000 00001000 gdiplus PE header Imag R RWE

7F7F1000 0016B000 gdiplus .text code,imports Imag R RWE

7F95C000 00008000 gdiplus .data data Imag R RWE

7F964000 00001000 gdiplus Shared Imag R RWE

7F965000 00012000 gdiplus .rsrc resources Imag R RWE

7F977000 00009000 gdiplus .reloc relocations Imag R RWE

Windows 8 32-Bit across reboots:

Address Size Owner Section Contains Type Access

00010000 00001000 gdiplus PE header Imag R RWE

00011000 00142000 gdiplus .text code,exports Imag R RWE

00153000 00002000 gdiplus .data Imag R RWE

00155000 00003000 gdiplus .idata imports Imag R RWE

00158000 00012000 gdiplus .rsrc resources Imag R RWE

0016A000 00009000 gdiplus .reloc relocations Imag R RWE

Enjoy!

This archive has a whitepaper that discusses research and methods used to circumvent Microsoft Windows 7 and 8 memory protections in order to execute arbitrary assembly code. Proof of concepts are also provided.

Download

http://packetstormsecurity.com/files/119835/Attacking-The-Windows-7-8-Address-Space-Randomization.html

Edited January 27, 2013 by Fi8sVrs