Protection Problems with MS08-001
Posted by Holly Stewart on January 17, 2008 at 6:55 AM EST.
Normally, we generally refrain from talking about products on this blog, but today, I'd like to make an exception to that rule. I'm a product manager, after all, so I tend to spend a lot of time thinking about them.
MS08-001 poses some unique problems from a remediation and protection standpoint. First of all, you have the update itself. It changes the core TCP/IP driver, and does so for a very good reason. If you don't already know the severity of CVE-2007-0069 patched in MS08-001, let me just say a few words here...
- affects all currently supported Microsoft operating systems
- on by default except on 2003 Server
- remotely exploitable
- requires no user interaction
This equals bad. More details at http://www.iss.net/threats/282.html
Being in the software development industry for some time myself, I know how tricky driver changes can be... and how they can sometimes go very, very wrong. Although I'm sure Microsoft has quality standards way beyond my wildest QA department fantasy, and I know they have a huge lab and excellent program dedicated to interoperability, it is difficult to predict how driver changes will interact with everything. If I were a customer running a network with a lot of home-grown apps that tapped into network drivers, this update would scare the bejesus out of me.
So, the goal of IBM ISS and many other vendors in our industry is to help our customers by providing interim protection and window of time to apply their patches. Most vendors, like us, attempt to provide protection from the perimeter all the way to the endpoint. Unfortunately, this was not so easy in the case of MS08-001.
Let me first say that the protection story on the network IPS side is very strong. No network-based exploit for this issue should make it to a segment protected by Proventia NIPS or Proventia Multifunction that is in blocking mode. And, because X-Force discovered this vulnerability, [start shameless plug] our customers have been secretly protected against this issue since Aug. 2007 [end shameless plug]. So, if you're one of our customers, and you have our protection at the perimeter and on each network segment, your network-based appliances are designed to stop any worm or bot from using this exploit to jump inside from the outside or from segment to segment.
Now, if you don't have network-based protection to the core and/or you rely on host-based products for protection at the core, the story, unfortunately, is not so happy. This leads to one of the things that make this set of vulnerabilities so unique. These issues are kernel-level vulnerabilities in TCP/IP and are so low in the stack that most host-based protection products would miss them. Even if you have IPS in your host product, the standard APIs that protection vendors hook into on XP and Windows 2000 do not provide protection at this low level in TCP/IP.
In the latest versions of our host software (Proventia Desktop 10 for Vista and Proventia Server 2.0 on 2003), we switched to a new, Microsoft-approved method of hooking into the TCP/IP stack (a new version of their officially supported API). We initially assumed that this API (like its predecessor) would not be low enough in the stack to allow PAM (Protocol Analysis Module, our IPS component) to provide protection. So, we erred on the side of caution and put out our advisory without host protection listed. After more research, we found that these new APIs do hook in low enough to provide protection as long as the Windows firewall is disabled. (If it is enabled, the firewall will prevent our host-based products from seeing the attacks and will not block them unless you have specifically configured it to block multicast—you other vendors out there using these new hooks in 2003/Vista may want to check this out as well.)
Older versions of our host software use a driver that hooks into the TCP/IP stack with a kernel patch and have no issue seeing and blocking this attack. Although patching into the kernel is not preferred by Microsoft, this particular driver has been used successfully in our host products since early 2003 and this method of patching has been used by the BlackICE product line (precursors to RealSecure and Proventia) since 1999. This driver is incredibly stable considering where it patches, and the fact that we didn’t have to update it to accommodate MS08-001 is a testament to that stability.
So, the problem with most host-based protection against this TCP/IP kernel vulnerability is that many products will never see an attack. Standard AV won’t work and neither would behavior blocking, including generic buffer overflow protection, because they don’t monitor at that low of a level and the exploit would never make it past the TCP/IP stack. For most, the only true way to protect against this attack is to apply the patch or disable multicast functionality in its entirety, which disables a lot of good things like some streaming media applications, some file distribution systems, etc.
So, to close this very long blog post, this particular issue is really a case study for having multiple layers of security. In the past, IPS was IPS, whether it was on the host or the network it protected the same way. This type vulnerability is a new type of exception and an example of why security research and a thorough understanding of threats is so critical to our business and absolutely required to provide protection to our customers.
