Didier Stevens

Tuesday 16 August 2011

So How Good is Pseudo-ASLR?

Filed under: Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 0:29

Let me first define what I mean with pseudo-ASLR. Address Space Layout Randomization (introduced in Windows Vista) loads executable files at different memory addresses. Studies have shown that ASLR uses 256 different base addresses and that the distribution is pretty uniform.

Pseudo-ASLR is what EMET and my tool SE_ASLR enforce. When a DLL does not support ASLR, memory at the base address of this DLL is allocated right before the DLL is loaded into the process. Since the address is not free, the image loader will load the DLL at a different address, thereby « randomizing » the base address. But how good is this randomization?

As I pointed out in my article on EMET, this base address is different each time a new process is started (unlike ASLR which needs a reboot for the base address to change). So maybe this is better ?

I developed a test program that loads a DLL but pre-allocates memory at the address of the DLL before loading. Then I ran that program thousands of times on a Windows 7 32-bit machine.

Running this program about 50.000 times gives me 68 different addresses. That’s by far not as good as 256 with ASLR. But what’s more important, is that the distribution of these addresses is not uniform at all:

There’s one address (0x000E0000 in my test) that is used 30% of the time. 2 other addresses are used 10% of the time. Rebooting the machine does not change this distribution.

When I do the same test, but enforce ASLR with EMET, I get a similar result:

Again there’s an address that is selected 30% of the time, but it’s different from my previous test. Rebooting the Windows 7 machine doesn’t change the address.

In this test, EMET uses only 15 different addresses, compared to the 68 addresses in the first test. I’ll have to research this difference, I’ve no explanation for it.

Conclusion from this simple test: pseudo-ASLR is rather weak, because I can predict the base address and I will be right one time out of three, which is not bad at all when I can launch my attack several times.

Wednesday 10 August 2011

Force “ASLR” on Shell Extensions

Filed under: My Software,Vulnerabilities — Didier Stevens @ 0:49

I’ve written about Shell Extension without ASLR support before.

Not only do they open up explorer.exe to ROP attacks, but other applications too, like Adobe Reader and Microsoft Office.

You could use EMET to force ASLR on these DLLs, assuming you know which applications load shell extensions. Because shell extensions are not only loaded into explorer.exe, but other programs too, I wrote a tool to force Shell Extension DLLs to load at another address than their base address, effectively simulating ASLR.

When my tool, SE_ASLR.dll, is loaded into a process, it will check for the presence of comdlg32.dll inside the list of loaded modules. When comdlg32.dll is used by an application, the likelihood of shell extensions being loaded into the process by user interaction with the file dialogs is significant.

Hence SE_ASLR will patch the IAT to intercept calls to LdrLoadDll. Each time the application loads a DLL (all DLLs, not only shell extension), SE_ASLR will check if the DLL supports ASLR. If it doesn’t, SE_ASLR will pre-allocate a memory page at the base address of the DLL, thereby forcing the loader to load the DLL at another address.

Although SE_ASLR’s primary goal is to relocate shell extensions, it will effectively relocate all DLLs without ASLR support once SE_ASLR is loaded into the process.

You need to load my tool into all applications that could use shell extension, for example via the AppInit_DLLs registry key. But before you do, be sure to test this out on a test machine. Not all shell extensions support relocation.

SE_ASLR_V0_0_0_1.zip (https)
MD5: 9D6AE1A96D554AEE527EB802FE59FB20
SHA256: 8A6C1406A757CD9788A2630D76A497E2C058333EE4D44CA0B85B2A05A39F257E

Wednesday 22 June 2011

Quickpost: Need a PoC to Test Your Security Setup? Not Necessarily…

Filed under: Quickpost,Vulnerabilities — Didier Stevens @ 13:30

People regularly ask me for a PoC (PDF or other type) to test their security setup. For example, they sandboxed Adobe Reader and now they want to test that Adobe Reader can’t write to sensitive Windows directories like system32.

Well, you don’t need a PoC to test your setup in this way. Just develop and compile a DLL that writes to system32, and inject it in the target process.

The problem however, is that not everybody has the skills to develop and compile such a DLL. But almost everybody can write a VBScript that accomplishes the same. Here’s a one-liner that creates test.txt in system32:


But how do you get the target process to execute this script? That is something I worked out 2 years ago: bpmtk: Injecting VBScript. In a nutshell: I developed a DLL that once injected into a process, instantiates a VBScript engine and executes the provided script.

Monday 13 June 2011

EMET Article

Filed under: Vulnerabilities — Didier Stevens @ 0:00

(IN)SECURE Magazine published my article on Microsoft’s Enhanced Mitigation Experience Toolkit.

It contains many details I’ve yet to discuss on this blog.


Monday 14 March 2011

HeapLocker: Null Page Allocation

Filed under: My Software,Vulnerabilities — Didier Stevens @ 5:03

Just like EMET, HeapLocker can allocate a page at address 0 (null or 0x00000000) to mitigate null pointer dereferencing.

I actually implemented this code in HeapLocker because I wanted to find out how one can allocate a page at address 0. You see, when you call VirtualAlloc with address 0, VirtualAlloc will allocate a page at an address chosen by VirtualAlloc, and not at address 0. So I would think that the trick is to call VirtualAlloc with address 1, and that VirtualAlloc will allocate a page that contains address 1, and that this page must start at boundary 0.

But the problem is that you get an error when you try to allocate a page at address 1 with VirtualAlloc. Ivanlef0u explains this in his blogpost (French). VirtualAlloc rejects addresses inferior to 0x1000, one must use NtAllocateVirtualMemory to successfully allocate address 1.

Friday 18 February 2011

HeapLocker: String Detection

Filed under: My Software,Vulnerabilities — Didier Stevens @ 12:43

A third protection technique I implemented in HeapLocker is string detection.

When you enable string monitoring, HeapLocker will create a new thread to periodically check (every second) newly committed virtual pages that are readable and writable. When a specific string (configured in the registry) is detected inside these pages, HeapLocker will suspend all threads (except this monitoring thread used by HeapLocker) and warn the user that the string was detected.

I’ve had very good result with this technique searching for string “unescape” in Adobe Reader (the string “unescape” must be preceded by an equal sign or followed by a left parentheses). Almost all malicious PDF documents in my collection were detected by this. But like NOP-sled detection, it’s not 100% reliable. Sometimes HeapLocker will scan a page before the string “unescape” has been written to that page.

Tuesday 25 January 2011

Circumventing SRP and AppLocker to Create a New Process, By Design

Filed under: Vulnerabilities — Didier Stevens @ 0:00

There’s an interesting comment on my Circumventing SRP and AppLocker, By Design post.

In my previous post, I showed a feature to circumvent SRP and AppLocker validation when a DLL is loaded.

The anonymous commenter points out a feature to create a new process, while circumventing SRP and AppLocker. Flag SANDBOX_INERT in function CreateRestrictedToken allows you to do this.


If this value is used, the system does not check AppLocker rules or apply Software Restriction Policies. For AppLocker, this flag disables checks for all four rule collections: Executable, Windows Installer, Script, and DLL.

When creating a setup program that must run extracted DLLs during installation, use the flag SAFER_TOKEN_MAKE_INERT in the SaferComputeTokenFromLevel function.

I wrote a small program to test this:

HANDLE hToken;
HANDLE hNewToken;

if (OpenProcessToken(GetCurrentProcess(), TOKEN_ALL_ACCESS, &hToken))
	if (CreateRestrictedToken(hToken, SANDBOX_INERT, 0, NULL, 0, NULL, 0, NULL, &hNewToken))
		memset(&sSI, 0, sizeof(sSI));
		sSI.cb = sizeof(sSI);
		if (CreateProcessAsUser(hNewToken, L"c:\\test\\Dialog42.exe", NULL, NULL, NULL, TRUE, 0, NULL, NULL, &sSI, &sPI))
			puts("process created");

This program starts another program, Dialog42.exe. I’ve configured SRP with a whitelist, Dialog42.exe is not whitelisted:

But when I use my program with the SANDBOX_INERT flag to start Dialog42.exe, it is allowed to run:

Monday 24 January 2011

Circumventing SRP and AppLocker, By Design

Filed under: Vulnerabilities — Didier Stevens @ 0:00

We’ve seen it countless times before. A vendor designs a security product, but punches a hole in this shield to accommodate developers. Yet, I still love the irony of it.

Software Restriction Policies and AppLocker can be configured to whitelist DLLs. But LoadLibraryEx has a feature (LOAD_IGNORE_CODE_AUTHZ_LEVEL) to circumvent SRP and AppLocker. From the MSDN documentation:

If this value is used, the system does not check AppLocker rules or apply Software Restriction Policies for the DLL. This action applies only to the DLL being loaded and not to its dependents. This value is recommended for use in setup programs that must run extracted DLLs during installation.

I’ve blogged about a spreadsheet that creates a DLL in a temporary location, and loads it inside the Excel process with LoadLibrary. It’s easy to block this DLL with SRP or AppLocker. But now I found out it’s also easy to bypass this, much easier than what I’ve done before. I just have to replace a call to LoadLibrary with a call to LoadLibraryEx, and pass it argument LOAD_IGNORE_CODE_AUTHZ_LEVEL. That’s all it takes to bypass SRP and AppLocker.

Let it be clear that this only makes it possible to load arbitrary DLLs inside existing processes, it does not allow you to create a new process that SRP/AppLocker wouldn’t allow.

If you use SPR/AppLocker, should you worry? It depends against what risk you use it.

When you use SRP/AppLocker to prevent common malware or other unwanted programs from infecting your machine, there’s no problem (now). If you use it on corporate computers to prevent your users from using software you don’t support, there’s no problem.

But if you use SRP/AppLocker as a security layer against (skilled) evil haxors, then you have to be aware that there is a large hole in your security layer and that it’s easy to misuse. In that case, you should better look out for another whitelisting security layer without “designer holes”. Unless it turns out Microsoft has a (hidden) setting to disable this feature, but I’ve not found one.

If this value is used, the system does not check AppLocker rules or apply Software Restriction Policies for the DLL. This action applies only to the DLL being loaded and not to its dependents. This value is recommended for use in setup programs that must run extracted DLLs during installation.

Tuesday 18 January 2011

Quickpost: Checking ASLR

Filed under: Quickpost,Uncategorized,Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 11:13

Some people asked me for a simple way to check shell extensions for their ASLR support. You can do this with Process Explorer.

Start Process Explorer, and set the lower pane to display DLLs. Select process explorer.exe, and add column ASLR to the lower pane view. Then sort on column ASLR.

You will see this:

Notice that on a default Windows 7 32-bits install all DLLs (with code) support ASLR. The n/a is for resource DLLs, they don’t contain code, and ASLR doesn’t apply to them.

Now open an explorer window and right-click a file, like this:

This action will load the context menu shell extensions.

Take a look at Process Explorer:

Now you see the shell extensions without ASLR support.

Quickpost info

Monday 17 January 2011

Quickpost: “It Does No Harm…” or Does It?

Filed under: Quickpost,Vulnerabilities — Didier Stevens @ 0:00

You often read about people who use many different security applications to protect their systems. Not only anti-virus, anti-spyware, firewall, HIPS, …, but also some other tools like anti-keyloggers, … And sometimes, when they argue about the additional protection such tools bring, you can read the following: “it does no harm…”.

Well, this time, I’ve a clear example where using a supplemental security tool does harm, even when it adds real protection.

When installed, this tool (which I’m not going to name here because of SEO reasons), installs a Windows explorer shell extension (we’ve discussed the risks of these shells before). The problem with this tool’s shell extension (a DLL), is that it is compiled without the dynamic base flag set. In other words, it doesn’t support ASLR.

On a default Windows Vista or Windows 7 install, all the DLLs of explorer.exe support ASLR. Even if a vulnerability is found in explorer.exe, it won’t be possible to bypass DEP and ASLR by borrowing code from a DLL to build an exploit with ROP gadgets. Unless you’ve installed this security tool, which adds a DLL with a fixed address to explorer.exe’s code space. Then an attacker can find ROP gadgets in this shell extension’s DLL.

This security tool harms the security of your system by opening it up to ROP exploits.

And shell extensions are not only loaded into explorer.exe. They find their way into many applications. For example, when you work with the common dialog control (like using the file open dialog)  in an application, shell extensions also get loaded into these applications. So this extension can get loaded into Adobe Reader, Microsoft Office applications, …

The risk this security tool brings to your system is not theoretical. There are malicious PDFs in the wild that use ROP gadgets.

Quickpost info

« Previous PageNext Page »

The Rubric Theme. Blog at WordPress.com.


Get every new post delivered to your Inbox.

Join 263 other followers