Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Microsoft Patch Tuesday Roundup - April 2010 - Superman Edition

It’s A Bird, It’s a DoS, It’s Remote Code Execution!

I've always cautioned people about the danger of disregarding vulnerabilities that are labeled as "Denial of Service" (Such as MS10-014 from February) for a couple of reasons. First, when a bug exists in the code that allows something to "crash", there is usually a potential that the "crash" could somehow allow for code execution (remember that a buffer overflow is just a controlled crash). Second, when code is being analyzed so that the bug can be fixed, the surrounding code is often analyzed to be certain there are no other bugs or vulnerabilities. This analysis could lead to the disclosure of other vulnerabilities or a new way to turn a DoS into remote code execution. This appears to be the case with MS10-20, which was first publicly disclosed as a DoS bug in the SMB client. Microsoft is now reporting it as a vulnerability that "could” allow remote code execution. Upon further inspection, the security bulletin reports five vulnerabilities related to the SMB client that are patched in MS10-20. The first is the original DoS bug reported by Laurent Gaffie to the Full Disclosure mailing list on November 11, 2009. The general consensus was to dismiss this bug because it was "just a DoS".

supergeek-sm.jpg


However, we now know that there are four other bugs associated with SMB, a protocol that has been in Windows since “Windows For Workgroups” appeared in the early 1990’s. We all thought it was astounding that there could even be one vulnerability in SMB that was recently discovered, but in fact, there are five of them! The scary thing is that the original DoS proof-of-concept code was published to the Internet. Anyone could have picked up where Laurent left off and tried to make something more of the DoS bug. You'd like to think that Microsoft first caught wind of this bug and started to analyze the code themselves and release patches. Wrong! It turns out that the other four bugs were "privately reported", which means that the researchers probably did not have the source code and discovered the remotely exploitable bugs through some other method such as reverse engineering. The big question is, “how many other people discovered these very same bugs but did not disclose them to Microsoft?”

All Hail The Mighty Firewall

In several of the recent Microsoft security bulletins, it is stated:

"Firewall best practices and standard default firewall configurations can help protect networks from attacks that originate from outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed."

I am a bit perplexed by this statement. First, what are "firewall best practices" anyhow? I did a little research and it seems to be something along the lines of:

"Allow only what you need (or can trust) and block everything else."

Now, there is certainly no need for SMB to communicate across the Internet, and I hope that everyone figured that out in 2003 when the NetBIOS-style worms (such as MS-Blaster) were running rampant. As far as what you can trust, that’s a pretty short list. Certainly anything that has access to the Internet should have its trust questioned. If you follow the previous two guidelines, I've stated, “firewall best practices” means that you should block all ports and all hosts. So much for firewall best practices. There is still hope, though. Maybe we can find some resolve in "standard default firewall configurations". A quick Google search reveals that this term seems primarily to only exist in Microsoft's own vulnerability bulletins! If this is the case Microsoft must provide us with some help to define "standard default firewall configurations", however that is not the case.

FirewallBug.jpg

While firewalls do provide some level of protection, they don't fix the real problem. The real problem is that the software contains a vulnerability, so rather than trying to slow down the attack, why not just fix the problem? True a firewall may buy you a little time, but its not an excuse to not the fix the real problem, which is going to exist whether you have a firewall or not and most likely means nothing if an attacker has already compromised a machine on your network.


Patch Tuesday Breakdown and Thoughts

What follows is a breakdown of the patches that have been released by Microsoft in the latest "Patch Tuesday" set and their associated Nessus plugins:

Resources