Windows Exploitation: ASLR Bypass (MS07–017)
By: Prashant Kumar
Tags: Security, Aslr, Windows, Ms07 017, Exploit

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:

ANI File Format

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)

MS07–017 PoC ANI file

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