Nov 30, 2011

Microsoft UDP Vulnerability: A Tester’s Perspective on MS11-083

by Todd Manning

In their November 2011 security bulletins, Microsoft released MS11-083 to address a vulnerability in TCP/IP rated as “Critical.” Taking a look at this vulnerability, and how to test it, provided some surprising results.

First, let’s talk about the vulnerability itself. The title of the bulletin is so juicy, I barely heard anything about the other bulletins this month: “Vulnerability in TCP/IP Could Allow Remote Code Execution.” That is exactly the type of vulnerability that had IRC channels in a frenzy to understand and, with any hope, exploit this bug.

Microsoft gave, seemingly, more detail in this bulletin than is typically found in bulletins:

“Reference Counter Overflow Vulnerability”

“A remote code execution vulnerability exists in the Windows TCP/IP stack due to the processing of a continuous flow of specially crafted UDP packets.”

“The vulnerability could allow remote code execution if an attacker sends a continuous flow of specially crafted UDP packets to a closed port on a target system.”

“…resulting in an integer overflow.”

Wow, a remote vuln in the TCP/IP stacks of Windows Vista, Windows Server 2008, and Windows 7 when processing UDP packets to closed ports! If this bug proved to be reliably exploitable, it had the potential to be “wormable”; that is, it could potentially infect from system to system, propagating across the Internet.

Microsoft’s Security Research & Defense blog released a post discussing the exploitability of MS11-083. This gave further information about the vulnerability:

“While processing these network packets it is observed that some used structures are referenced but not dereferenced properly. This unbalanced reference counting could eventually lead to an integer overflow of the reference counter. …

“If a dereference happens just after the counter has wrapped to zero, the structure will be freed.”

That sounds promising. The first question I asked myself was, “What is the size of this reference counter?” It turns out to be a 32-bit counter. So on the face of it, this vulnerability requires 2^32, or 4,294,967,296, UDP packets to be sent to a closed port on a vulnerable system.

MS11-083: The Test Methodology

As soon as I realized this, I knew that the BreakingPoint CTM could create this scenario. And while many people speculated on the time required to send 4 billion packets, in one case estimating over 50 days, I knew this was not the case. In a test with the ports in loopback, a BreakingPoint CTM, at a rate greater than 1 million packets per second, can reach 4 billion packets in less than two hours.

Several researchers had posted about the topic, but I found this blog post by Byoungyoung Lee and Yeong Jin Jang to be the best. In their post, Lee and Jang go into great detail about the structures and code involved in this bug. Their testing methodology is to artificially set the reference counter to a value close to the maximum to reduce the number of packets that must be sent to integer-wrap the reference counter and exercise the bug.

My method would differ from this, because I want to figure out what really happens when you trigger this condition naturally. Microsoft gave the following possibilities on their Security Research & Defense blog:

“If a dereference happens just after the counter has wrapped to zero, the structure will be freed. Depending on the timing conditions, four scenarios are possible:

The memory is still mapped and contains the old data. No crash results and the system works as normal.
The memory is unmapped and the system crashes when it is referenced. This results in a system denial-of-service.
The memory is re-allocated for the same structure. No crash results and the system works as normal.
The memory is re-allocated for a different structure. This could result in a system crash, or if attacker-controlled data is present, could lead to memory corruption or remote code execution.”

Is this true? Are these the four possible results? They sound reasonable, and while you can read about the disassembly of the Microsoft TCP/IP stack, unless you actually test this bug it’s hard to say exactly what would really happen. The possibility of multiple outcomes makes rapid testing essential.

The first path I chose was to take a virtual machine running Windows 7 and start testing. Of course, the theoretical maximum rate of more than 1 million packets per second was not going to be realistic. If a virtual machine could handle and generate such a rate, there wouldn’t be a need for the monster that is our product.

I calculated the packet rate from the virtual machine’s perspective and estimated the time of completion to be about 8 hours. My test continued running that day, and that evening I anticipated seeing what everyone seemed to contend would be a BSOD (Windows Blue Screen of Death), indicating that the kernel had crashed. The prospect of causing a kernel crash motivated me to return to the office in the middle of the night to see it.

And the result? Drumroll…

MS11-083 Testing: Accurate and Fast

The result was that the VM was frozen. My host OS was still running happily, but the VM was just…frozen. No blue screen, no visual indication of anything wrong; this was a real letdown. I reset the systems and started the test again, but this initial result made it apparent that virtualized Windows 7 running on a MacBook Pro was likely not the best platform for this type of test.

And because I could test this vuln quickly, I decided to make some changes to the rig. I would dual-boot the Apple laptop and run Windows 7 “bare metal,” meaning no virtualization. While the first test froze the VM, this second test yielded a different result. The VM user interface was responsive, and I could poke around Windows 7 and see what was going on, including the loss of network connectivity for the target. I tried to ping the network and nothing happened, but the host OS was still on the network, so I was confident I had exercised the bug.

Because I expected to be making several more attempts, I tuned the target as best as I could to get the maximum packet rate possible. In the target’s default state, I was able to achieve a UDP port-unreachable error rate (from the target’s perspective) of about 110,000 packets per second. But I hoped to go faster, so I made some configuration changes, including removing a delay in my superflow:

After performing these changes, I saw an increase of about 70,000 port-unreachable errors per second. There may be other improvements that could be made, but these were quick and reduced the average time to test by more than 2 hours.

With these changes, I tested this vulnerability more than a dozen times. In all those tests, I still failed to observe the much-ballyhooed BSOD, which I so expected to happen that I had actually pushed off submitting this blog post, sure that I would eventually witness it.

No BSOD but an Interesting Result: Information Leak

Although the BSOD eluded me, I found another interesting result beyond the frozen VM and loss of network stack (although that last one had me thinking of some situations where a lasting network DoS would be useful). The most interesting result I saw was an information leak.

I’d configured one of my tests to run for 6 hours overnight, and when I checked on the progress the next morning, I saw the test had failed. The BreakingPoint CTM reported that the remote interfaces went down. This was great news, and I immediately interrogated the Windows 7 target. Surprisingly, the system was still up. Not only that, its networking stack was functioning normally. I scratched my head. I wished I’d been around at the moment the bug was exercised.

Going back to my desk, I thought about what to do next. My time machine project has been languishing, and not wanting to tempt fate by altering the space-time continuum, I realized I had the next-best thing to a time machine: BreakingPoint CTM’s packet capture buffer!

I was lucky the interface on the target machine dropped, because presumably this stopped the test right at the moment the bug triggered. The packet export screen provides the capability to perform filtering on the packets being exported. I used this to grab just the last few hundred packets from the test. What I saw took me a minute to fully comprehend.

In these final packets, I saw two hosts (simulated by the BreakingPoint Storm) communicating with the target. I’ll designate Host A as IP address 1.1.237.8, which is shown in green in the screenshot, and Host B as IP address 1.1.183.108, shown in red.

We can see that Host A sends a UDP packet, and then host B sends a couple of UDP packets. After this, we see the target ARPs for Host B’s Ethernet MAC address, and a malformed ICMP packet is shown last. It’s this ICMP packet that proves interesting.

When a UDP packet is sent to a closed port, the stack will send back an ICMP “port unreachable” message. The ICMP payload will include the first several bytes of the UDP packet, so the offender can determine which UDP port was closed.

Take note: this ICMP packet is sent to Host A but contains an ICMP message intended for Host B. Furthermore, 10 bytes of Host B’s UDP payload is sent to Host A. So the information leak in this example would tell Host B that Host A was sending UDP packets to closed ports, along with at least some contents of the packet. With this information, you might be able to know the IP address of a host that was scanning your target with nmap.

Conclusion: Test Everything...Because You Can

Normally, security researchers like me analyze vulnerabilities like this by taking a more traditional approach of reverse-engineering patches. Because this bug is so unique in the amount of network traffic it needs to send, using the BreakingPoint CTM allowed me to take an unconventional approach to security research. With this ability to quickly create exact vulnerability scenarios, no matter the amount of traffic, you can actually test everything, all the time. This will help you ensure that your systems behave the way they should when faced with these situations or that your systems find and fix any possible problems before they happen in the real world.

Related Content:

Network Security Testing

Test Methodologies