Microsoft’s security patches year in review: A malware researcher’s perspective
It’s no secret that Microsoft has had the lion’s share of security vulnerabilities. Its success as a company has made it the most obvious and profitable target for malware authors for nearly twenty years now. While it is true that we are seeing malware authors begin to attack other pieces of software, to the tune of up to 84%, according to Microsoft’s Security Intelligence Report v7, the fact remains that because of its ubiquity, the Windows operating system will continue to be the number one target for bad guys for a number of years to come. A Microsoft representative from the Netherlands has even gone on record saying Microsoft does not want malware on other operating systems, because that would then mean that the competitor is successful.
While it may seem no different than any other year, Microsoft has had a pretty hectic past 12 months on the security front. In one regard, they have made enormous strides in creating a more secure operating system starting with Windows Vista and culminating with the just released Windows 7. On the other hand, they’ve issued several out-of-band security patches and would of course love for everyone to forget about the Conficker (AKA Kido/Downadup) worm. Even pre-release versions of Internet Explorer 8 and Windows 7 were hit with critical security vulnerabilities. In the past year, Microsoft has released four out-of-band patches addressing MS08-067, MS08-078 and they released MS09-034 and MS09-035 on the same day. In December ’08, they addressed 28 vulnerabilities, in June ’09 they addressed 31 vulnerabilities, a record at the time, and then in October ’09, they beat two records; the most patches with 13, addressing the most vulnerabilities at 34. It has certainly been a busy twelve months in Redmond.
Security philosophies
There is a holy war in the security industry that has been going on for some time now. The one side says that security patches should be released as soon as humanly possible: a known vulnerability is a security risk no matter what. The other side though, says that if a vulnerability has been discovered internally by the company, or has been responsibly disclosed, that the simple act of issuing a security patch might be as risky as not issuing a patch. Both sides have their merits for sure which makes choosing sides fairly difficult.
The second camp says that whenever a company such as Adobe or Microsoft discovers a vulnerability, fixing it immediately is not always the best choice, especially in the case that the exploit is not publicly known, such as when Microsoft discovers the vulnerability itself, or when someone has disclosed their vulnerability responsibly. It frequently happens that malware is created to exploit vulnerabilities by reverse engineering the patches that Microsoft releases. In some cases, if Microsoft were to delay release of a security patch, they can also delay the release of malware that exploits that vulnerability. The first camp however says that the second camp is relying on some potentially false assumptions. Just because it is thought that the vulnerability is not known by others, does not mean that it truly is not known by others. Perfect examples of this is the SSL certificate spoofing vulnerability that both Moxie Marlinspike and Dan Kaminsky presented about at Blackhat this year and even more to the point, another SSL implementation flaw was stumbled upon on November 4th. This disclosure happened exactly as the second camp warns: a silent security fix was being planned by a group of people under the assumption that nobody else would find out until after the fact, and surprise, a third party came along and posted his findings without fully realizing the implications.
Microsoft has long had a history of prioritizing functionality and ease of use over security, however, this year marks two big strides at correctly prioritizing security. Internet Explorer 8 has been made available on Windows XP, and along with it, the security improvements it brings, especially when compared with Internet Explorer 6. Even more impressive however, is that Microsoft made available a patch for disabling the autorun feature on rewritable media such as USB drives or network shares. Security professionals have been screaming about this so called feature for years and we finally got it. This is a giant win for organizations still running Windows XP, and large majority still are, as removable media has regained its once prominent role as a prime infection vector in recent years due to the widespread usage of portable USB thumb drives.
As somewhat of an expert it’s always interesting to read about the various security vulnerabilities. Most people, including software developers, have no idea how much effort goes into creating truly secure software. Software development in general is a tough thing. There is a reason why the majority of projects are over budget and late, and that’s just for core functionality, most software development teams completely excludes security concerns from their development cycles. Now add in security on top of the regular development cycle and it becomes easier to understand why even organizations such as Microsoft, who by all measures is an expert at delivering software, frequently find themselves at the butt end of a security vulnerability. When Java and .NET were released, people hailed them as the end of insecure software, gone are the days of buffer overflows. Well, the bad news is that security vulnerabilities are more than just buffer overflows and failures to correctly handle strings correctly.
MS08-067 – Conficker and friends
Without a doubt, the most publicized exploit of the year was due to the MS08-067 netapi32!NetpwPathCanonicalize. This is a prime example of the “security is hard” mantra. As it turns out, Microsoft had issued a patch addressing the same area of code two years prior with MS06-040. Nobody but Microsoft can tell you why they failed to catch the other errors, and good luck getting them to do so, as they would much rather forget the entire thing ever happened, but it goes to demonstrate exactly how hard security truly is.
The decision by Microsoft to release an out of bound patch for MS08-067 was triggered by the public availability of proof-of-concept code for the vulnerability followed by malware that was actively exploiting the vulnerability. The malware families in this case, according to Ziv Mador, speaking at CARO 2009, were Gimmiv, Arpoc and Wecorl among others. Most people have heard of Conficker, however most industry outsiders probably have not heard of Gimmiv and the other lesser known malware exploiting MS08-067. The reason is obvious in the sense that in order to become well known, malware has to be widespread. The reason this was the case for Gimmiv, at least, was simple; it drops a batch script to delete itself after having executed its payload. This and the sole reliance on MS08-067 to spread had significant impact on its overall penetration.
For security professionals, November 21st will be remembered by many as a day of infamy, right alongside January 24th and August 12th 2003, the dates when Slammer and Blaster were discovered. For me, it was work as usual; stumble upon a pretty normal looking piece of malware, write a detection for it and move on. Little did I know at the time how truly remarkable both the malware and the name I chose, Conficker, would end up being. Conficker as we all know has been one of the most effectively propagating pieces of malware since the days of Sasser, Slammer and Blaster. Microsoft made an excellent decision to release the patch for MS08-067 almost a month prior to the appearance of Conficker and had Microsoft not released the patch, and had the Conficker Working Group not devoted so much effort, the story behind Conficker could have been much worse. The days when unpatched copies of any operating system were safe on the network have been over for at least a decade, but as the saying goes, you can lead a horse to water, but you can’t force it to drink.
Conficker was so successful at infections due to a variety of reasons. First, Conficker patched the MS08-067 vulnerability so as to both prevent re-infection and to protect itself from other malware exploiting the same vulnerability such as the previously mentioned Gimmiv. Second, Conficker.B, started spreading via removable media such as USB sticks and via weak security controls in network shares and also attempts to brute force passwords on the infected machines to gain further access to network resources.
The C++ template nightmare
Most other security related events this past year pale in comparison to Conficker and MS08-067, but that still doesn’t mean they are uninteresting. A highly interesting example from the point of remediation was the slew of vulnerabilities related to the ATL C++ template libraries. Talk about a nightmare to fix. First off, there wasn’t a simple binary that could be replaced, in order to actually fix the issue Microsoft had to provide an update to the ATL source code which means that in order to fix the vulnerability, developers need to recompile and reship their products, and, unless the developer is aware of that requirement, they will still have vulnerable products. It took Microsoft, for example, a total of three months to completely address the issue in their own products. They issued the ActiveX kill bits only July 14th, with MS09-032, on July 28th they had the two out of band patches, one addressing Internet Explorer, and the other addressing the ATL C++ source code that is shipped with Visual Studio. Windows Live Messenger received an update on August 25th and on October 13th, Microsoft was finally able to address the vulnerability in Office. The sad thing is that a large number of independent software developers will likely be unaware of the actions they need to take in order to protect their customers, and will thus be exposing their customers to the same vulnerability. Similarly, it is possible that Microsoft will be releasing more killbit updates for ActiveX controls as they become aware of them. Microsoft has provided a flow chart.
Data Formats are hard
There were several interesting vulnerabilities related to incorrect handling of various data formats. MS09-028 and MS09-059 were both related to the differences in formats between C strings and pascal strings. The core issue for both vulnerabilities is that dealing with structured data, especially when created by different groups of people, is extremely hard and error prone. And, for those interested, The Art of Assembly Language gives a fairly detailed description of the various string formats that are at issue here.
MS09-059 was made famous at Blackhat Las Vegas 2009 by Moxie Marlinspike. Dan Kaminsky also discovered the vulnerability but I think Moxie stole the show with his energy and delivery. Briefly put, C strings use null sentinel characters to designate the end of a string whereas pascal strings use length prefixes to designate string content. Certificate authorities use the pascal convention while virtually every implementation using these certificates use the C convention, hence the vulnerability. It appears that exploitation of this vulnerability has been relatively limited, but due to the nature has received a widespread press.
MS09-028, however, was not so limited. Anti-virus companies quickly discovered that malware authors were exploiting the vulnerability in order to infect victims with a password stealer that targets players of certain online games. This vulnerability, as with MS09-059, was again caused by the difference between C and pascal like string formats.
Following an ongoing trend in recent years, we saw MS09-006, which was a vulnerability in EMF/WMF image files. There were some poor design decisions here that increased the significance of the vulnerability because EMF and WMF images can have their extension changed to .jpg and still be recognized as valid EMT/WMF images. The especially alarming part here is that these images are handled by kernel mode code, a design decision that is potentially twenty years old, and it was this kernel mode code that was vulnerable.
Internet Explorer 8
Internet Explorer has had its share of battle wounds this year too. Besides security vulnerabilities, Betanews reports that the result of cumulative security patches has resulted in the once fast Internet Explorer 8 becoming only marginally faster than its predecessor. To borrow from Steve McConnell in Code Complete: sure your code may be fast, but mine would be faster if it didn’t have to be secure.
Microsoft didn’t catch a break in the last quarter of ’08. Hot on the heels of Conficker, December brought another out-of-band patch addressing a data binding vulnerability that would result in drive by exploitation. MS08-078 was released only 8 days after patch Tuesday fixed had already addressed 28 vulnerabilities. I during the last two months of 2008.
March of 2009 brought Internet Explorer 8, which brings fully enabled Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP or NX) to the browsing experience. The final release version, however, was beat to the punch by the Opera browser, which enabled the same features about two weeks prior to IE 8’s final release date. It’s significant to note the work of Mark Dowd and Alexander Sotirov on bypassing ASLR and DEP. Because of their work, a relative newcomer to the exploit field, who chose go by the name of Nils, was able to create quite a stir while participating in CanSecWest’s pwn2own contest. It was first thought that the exploit was achieved on the released version of IE 8, however, that turned out to not be the case. The final release of IE 8 included a fix to prevent the type of attack as outlined by Dowd and Sotirov and was therefore not vulnerable to the exploit. A patch was still required to resolve the vulnerability because, as we all know, ASLR is not available on Windows XP, and on 32 bit systems it is still possible to brute force. Lastly, it is still possible to disable DEP and ASLR and re-enable the feature at the heart of the ASLR+DEP bypass. I mention this because there was some confusion around why Microsoft would issue a patch for a vulnerability that its product was already protected against.
Conclusion
It’s been an interesting year this year. A lot of things happened, Conficker, Internet Explorer 8, Windows 7, etc. The security story for Microsoft keeps improving, yet it seems to have no effect on the malware and exploit writers’ ability to discover new ways to infect users systems. As fast as security tools evolve to discover and fix new vulnerabilities, new ways are discovered to bypass them and this year has been no different in that regard. For the sanity of the world, here’s hoping for a boring 2010!