Rapid7 Blog

Exploiting the ANI vulnerability on Vista

POST STATS:

SHARE

There's been some discussion going around about whether or not it's really possible to use the ANI vulnerability to execute arbitrary code on Vista. If you aren't familiar with the ANI vulnerability, go check out another great bit of work from Determina's Alexander Sotirov. HD Moore wrote the first Metasploit module for this on Friday night and we continued to improve the exploit (and add a second SMTP module) over the weekend. These modules include a default target that is able to hit both XP and Vista. Due to the nature of the vulnerability, it's possible to try multiple targets, even if they lead to a crash.

I won't go into the details of the vulnerability. You can read Alex's excellent description of the issue. Instead, this post will focus on illustrating that code execution on Vista is most definitely possible. Many would assume that this vulnerability would be stopped by one or more of GS, DEP, ASLR, and Protected Mode IE7 on Vista. That's not the case, though.

As Alex points out, the vulnerable function does not properly make use of GS. This makes it possible to trigger a traditional stack-based buffer overflow on all affected versions of Windows. In addition to GS not being present, DEP is disabled by default for Internet Explorer and Windows Explorer on 32-bit Windows Vista. This means that non-executable pages will not be enforced. And that brings us to ASLR.

On the surface, it would seem as though ASLR would be sufficient to prevent this attack from working reliably. However, due to the nature of this vulnerability, it's possible to trigger a partial overwrite of the return address on the stack. In Vista, and indeed other versions of Windows, the two low order bytes of any address in an image file mapping will not be affected by ASLR. This is due to the minimum allocation granularity in Windows. Even though partial overwrites of the return address are possible, an attacker must be able to find a useful instruction on the same 16 page block as the return address being partially overwritten. For example, if the original return address was 0x74310368, a useful instruction must be found within 0x7431XXXX. An alternative to using a partial address overwrite would be to simply brute force around 256 combinations of absolute addresses, since it's possible to trigger this issue multiple times without crashing the IE process.

One last thing that's worth mentioning. It has been proposed that low rights (protected mode) in IE7 on Vista may prevent the exploitation of this issue. First and foremost, this is not true. While it may prevent the explicit execution and interaction with certain system resources, it does not prevent arbitrary code execution. For example, the Meterpreter payload included in Metasploit is able to execute reliably, even in protected mode IE7. This is because Meterpreter does not spawn any external processes on its own. Of course, if you attempt to execute something from within Meterpreter, it will fail as a result of protected mode IE7. Even though this is the case, I think that further research may provide insight into ways of breaking out of protected mode.

So, given these facts about GS, DEP, ASLR, and protected mode IE7, it's possible to go ahead and write a functional proof of concept that will work on Vista. When triggering the vulnerability on Vista with a complete overwrite of the return address, the register state looks something like this:

There are also other contextual references that contain parts of, or point into, the RIFF image. The esp and edi registers contain the first ANI header found in the file. The esi register points to an ANIH chunk. For the purpose of this post, only the references found through the ebx register will be considered, though I did investigate these additional avenues to some degree. In Metasploit's existing ANI exploit, you'll see that HD has provided a target for Windows XP that uses a partial overwrite to point the return address at a location that contains a call [ebx 4] instruction. However, there are no immediately equivalent call [ebx 4] instructions within the required 16 page block on Vista:

0:006> s 775b154c L?ef00 ff 53 040:006> s 775b154c L?ef00 ff 63 04

Even though there are no call [ebx 4] instructions, there are a few jmp [ebx] instructions:

This means that if the two low order bytes of the return address are overwritten with 0x700b, the vulnerable function will transfer control into a jmp [ebx] upon return. The jmp [ebx] will start executing code starting with the beginning of the RIFF image itself. The first four bytes of the image is the RIFF chunk tag ("RIFF"). This disassembles to four nop-equivalent instructions shown below:

While these four initial bytes won't cause problems, the four bytes that follow them might. The field that follows the four byte tag is a four byte size which represents the size of the chunk, excluding the header fields. This really isn't much of a problem, though. Since we control the RIFF image that is being generated, we inherently control its size. While we can't reasonbly use all four bytes (since this would require a large RIFF), we can definitely make use of at least the two low order bytes. Padding out the RIFF chunk makes it possible to explicitly control the low order bytes.

With this in mind, the next step is to figure out exactly which instruction the low order bytes of the size field should be set to. We're fairly limited here, but a two byte short jump seems like a good option. Due to the way that the RIFF chunk is set up, its contents will look something like this in memory:

Using this basic layout, we can insert a special embedded chunk as the first entry after the ACON tag. The purpose of this embedded chunk will be to act as a target for the short jump used in the RIFF length field. As such, the embedded chunk should contain additional code to execute. While it's entirely possible to have the embedded chunk contain a payload itself, the Metasploit exploit instead places a long jump that transfers control to the first byte after the end of the RIFF chunk itself. This makes the exploit uniform with XP in terms of how it executes the payload.

I know I left out a lot of details, but let's put the whole thing together. First, you can perform a partial overwrite of the return address using 0x700b. When the vulnerable function returns, it will return into a jmp [ebx] instruction. This will transfer control into the start of the RIFF image, starting with the RIFF tag. The two low order bytes of the RIFF chunk size field can be set to 0x0eeb which is a short jump 16. This short jump transfers control into the data portion of an embedded chunk. The data portion of this embedded chunk contains a relative jump to the payload that has been appended after the containing RIFF chunk.

It's definitely possible (and likely) that there are cleaner ways to go about this, but this at least illustrates one way of going about it. It's clear that a partial overwrite of the return address is one of the best solutions in this case. The only major point of contention in this approach centers around what to overwrite the low order two bytes with.

POST STATS

SHARING IS CARING

AUTHOR

Want more? Don’t miss these posts

Metasploit is pleased to announce the immediate free availability of the Metasploit Framework version 3.0 from http://framework.metasploit.com/.The Metasploit Framework ("Metasploit") is a development platform for creating security tools and exploits. Version 3.0 contains 177 exploits 104 payloads 17 encoders…

If you were able to attend Black Hat Europe this year, you had the opportunity to catch Alexander Sotirov's talk on Heap Feng Shui. If not, I recommend you take a look at the materials found here . The focus of his talk was on…

Featured Research

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Toolkit

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Featured Research

Rapid7’s Quarterly Threat Report leverages intelligence from our extensive network—including the Insight platform, managed detection and response engagements, Project Sonar, Heisenberg Cloud, and the Metasploit community—to put today’s shifting threat landscape into perspective. It gives you a clear picture of the threats that you face within your unique industry, and how those threats change throughout the year.