Windows Exploitation: ASLR Bypass (MS07–017)

7 min readMar 3, 2019

In this blog, I will be analysing a long forgotten Windows Animated Cursor Remote Code Execution Vulnerability (CVE-2007–0038) on Windows Vista. It was a classic case of a random not being random enough. A bit of a backstory before we move on…

Few days back while scrolling Twitter, I found this amazing story about inception of ASLR from John Lambert, a cool guy from Microsoft Threat Intelligence Center.
(Follow him, and *shameless grin* follow me too)

And while you are at it, you just might want to look at this thread to understand why Windows Vista was not wrong, just ahead of time:

OK, no more threads. And yes, you have every right to hate Vista, or hate Windows. The reason why I started with the story of ASLR and then Windows Vista is that many people out there remember MS07–017 as a slap on the face of Windows Vista’s security when it clearly is not the case. Yes, researchers were able to bypass the protections (ASLR) in Windows Vista, but these protections didn’t even exist in XP in the first place! Advising users to roll back to XP was plain stupid!

With this misconception out of our way, let’s move forward and understand the vulnerability first. For that, we need to understand how ANI files work.

The ANI files

The vulnerability lies in the way ANI headers are handled in Windows. So what are ANI files? ANI files are animated mouse cursors that are used by Windows. These files follow the RIFF file format that was developed by IBM and Microsoft. I’m not going to delve into a lot of details of how RIFF works, will keep it limited to the knowledge we would need.

RIFF File Format

RIFF file format stores data in chunks. For ANI files, there are mainly two types of chunks- anih and LIST. anih (ANI Header) chunk stores the metadata about the file and LIST stores the actual data. Here is an example of an animated cursor:

The bytes marked with-
Red: “RIFF” itself. Indicates the file follows RIFF file format.
Orange: The length of rest of the file
Yellow: “ACON”. The header ID. Indicates the file is ANI file.
Green: “anih”. Denotes the beginning of anih chunk.
Blue: Size of chunk. 0x24 or 36 bytes.
Purple: Rest of the anih chunk.

After the anih chunk, there is a LIST chunk (like anih chunk, its size is in next 4 bytes and the data thereafter) but we are interested in anih chunks only. If you want to know about what all data is stored in ANI header (the purple part), you can look at Structure of the ‘anih’ header chunk section here. Enough background for now.

The Vulnerability

Windows uses a function LoadCursorIconFromFileMap to use ANI files. It didn’t validate the size of anih chunks, anything above 36 bytes lead to an overflow, and Microsoft fixed this in MS05–002. In the patch, the function started validating the anih header size to make sure it is 36 bytes only. Unfortunately, it was only validating the first anih chunk.

LoadCursorIconFromFileMap function internally calls LoadAniIcon which loads all the chunks. LoadAniIcon function do not validate size of any chunk. So, if an ANI file is having two anih chunks, the first one being valid 36 bytes header and second one being fatty malicious one, will bypass the mitigations of MS05–002 and will result in overflow in LoadAniIcon function.

Proof of Concept code

The researcher who found this vulnerability released a PoC ANI file which replicates this overflow:
(You can use this python script to create this file yourself)

In this PoC we can observe two anih chunks. First one is perfectly valid healthy 36 bytes chunk. Second chunk is a fatty 88 byte (or 0x58 bytes) anih chunk which will lead to an overflow. For those of you who are wondering why we have random nulls in second chunk, read the comments in line 476–488 of the metasploit module of this vulnerability.

But how will we deliver this payload? We will have to make Windows load this ANI file for that. There are multiple ways of doing it but best case scenario would be to deliver this ANI file remotely to the system. That way we will have a remote code execution! We can make victim open a malicious webpage, webpages can define custom cursors. Or we can send an HTML formatted mail to the victim. All you have to do is create a webpage with following code:

<html> <body style="cursor: url('exploit.ani')"> </html>

Let’s see this PoC in action:

Great! PoC works. But a curious mind would question WHY. This is Windows Vista. The program must have been compiled with Stack Canary (GS flag). But nope, it wasn’t. Compiler chose not to. As it will turn out later, DEP is also disabled for Internet Explorer. If you want to learn more about why these protections were absent, have a look at Matt Miller’s analysis of this vulnerability.

The exploitation

So we have 43434343 written in EIP. How about finding a JMP ESP now? But hold your horses. We have ASLR enabled here in Windows Vista. Even if we find an address to JMP ESP, it’ll get changed after we restart the system. Right… RIGHT? Well, sort of. The address indeed will change, but only the first two bytes. Here’s an example:

Note the address of JMP ESP in first image. And then look at it in second image. You can see the difference ASLR is making- changing only first two bytes while keeping last two constant.

Because of the way stack is laid out, when our exploit would be overwriting the value of EIP, it would first be overwriting the fourth byte, then the third byte, then the second byte and finally the first byte. This means that if we overwrite only two bytes in EIP, we would overwrite the last two bytes. Let’s replicate this first. We would modify our PoC to only overwrite 4343, not 43434343.

Note that I have modified the size of RIFF and second anih chunk too (highlighted in yellow). After using this ANI file, this was the overwrite we’ll get:

Great! Now we have to find a JMP ESP in the range of 77B5XXXX. Why? Let’s say we found a JMP ESP at 77B57A90. Now, even if the system restarts, this JMP ESP will shift to let’s say 76A17A90 or 77B17A90 or 749B7A90, the last two bytes are always constant aaaand our exploit will overwrite just these two bytes.

So we start searching the 77B5XXXX range for JMP ESP, but no luck. Looking at other registers, we do have a JMP [EBX] instruction in the range:

And EBX looks interesting too. It holds the address of the beginning of our ANI file.

From Registers pane, we see EBX holds value 02BFF0EC which point to value 02D50000. In the dump, we can see the value at 02D50000, it points to our ANI file. If we look at our file as instructions in Instructions pane, that “RIFF” would convert to weird (but safe) instructions.

Before proceeding further let’s verify if our theory of jumping to beginning of our ANI file is working or not. We can safely replace the 4 bytes after “RIFF” with anything. So let’s put an INT3 instruction there. Here is how our ANI file would look like:
(Code for creating this file is here)

The EIP will be overwritten with 700b, which should point to JMP EBX. Let’s put a breakpoint at this instruction to verify.

As we can see here, we did hit our breakpoint at JMP [EBX] and then started executing our ANI file. But how and where do we put our payload? We can only use the 4 bytes after “RIFF”, we cannot overwrite “ACON” and anih chunk after that. What we can do is place our payload after valid anih chunk and place a short jump in bytes after “RIFF” to jump to the payload. Currently, our ANI file is looking like this:

RIFF + size + ACON + valid_anih + exploit_anih

We can do something like this:

RIFF + [JMP payload] + ACON + valid_anih + payload + exploit_anih

Time for some venom! The code for generating our final ANI file:

And this is our final ANI file:

With this ANI file in place, we finally have a this:

Oh, yeah!