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".
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.
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:
- MS10-019 - Nessus Plugin ID 45506 (Credentialed Check) - Opening certain files, such as CAB, allows for remote code execution.
- MS10-020 - Nessus Plugin ID 45507 (Credentialed Check) - This is the patch for the five vulnerabilities associated with SMB.
- MS10-021 - Nessus Plugin ID 45508 (Credentialed Check) - There are several vulnerabilities associated with the Windows kernel. One of them could lead to the creation of "Windows reboot web sites". CVE-2010-0482 is one of the vulnerabilities addressed in this bulletin and is described by Microsoft as "A denial of service vulnerability exists in the Windows kernel due to the improper validation of specially crafted image files. An attacker could exploit the vulnerability by running a specially crafted application causing the system to become unresponsive and automatically restart.". Sometimes as an attacker you need the system to reboot, but don't want to just reboot it out of the blue, so this may be a good way to do just that. All you have to do is send them a message "Click here for a free
" and take them to a page containing the image that causes a reboot. There is also a neat privilege escalation exploit that uses registry links fixed in this bulletin as well.
- MS10-022 - Nessus Plugin ID 45509 (Credentialed Check) - This is the infamous "F1" key bug. You can apply this patch, or remove/disable the F1 key for all of your users.
- MS10-023 - Nessus Plugin ID 45510 (Credentialed Check) - This is a vulnerability in Microsoft Office that is triggered by opening a Publisher document. It would be interesting to harvest Publisher users from the public discussion forum and target them with this exploit.
- MS10-024 - Nessus Plugin ID 45511 (Credentialed Check) and Nessus Plugin ID 45517 (Uncredentialed Check) - Vulnerabilities in SMTP are scary as the service needs to be exposed to the Internet in order to send and receive email. DNS is in the same boat and is also referenced in the MS10-24 bulletin. Even though this is a DoS vulnerability you should patch it ASAP. Exposed services lead to compromise.
- MS10-025 - Nessus Plugin ID 45512 (Credentialed Check) - First, if you are exposing a Microsoft Windows 2000 server to the Internet, you are just asking for trouble. Second, if you are still using Windows 2000 on the "inside" of your network, you are just asking for trouble.
- MS10-026 - Nessus Plugin ID 45513 (Credentialed Check) - This vulnerability represents an "AVI file of death" that could contain an exploit for the MPEG-3 codec. I wonder how well AVI files make it through email filters? They must have switched codecs for Windows 7 (but not Vista) as Windows 7 is not affected.
- MS10-027 - Nessus Plugin ID 45514 (Credentialed Check) - A remote code execution in Windows Media Player 9. If you are running this, you need to upgrade to version 11.
- MS10-028 - Nessus Plugin ID 45515 (Credentialed Check) - Another bug in Visio resulting from a "specially crafted" file being opened that "could allow" remote code execution.
- MS10-029 - Nessus Plugin ID 45516 (Credentialed Check) - This is an interesting attack that allows for spoofing of IPv6 source addresses, which can then be used to bypass firewall rules. This really sums up this month’s patch Tuesday as Microsoft is recommending firewalls be used to prevent attacks, but has also released a patch for a vulnerability that allows firewalls to be bypassed.
- OSVDB Microsoft Bulletins - Complete Reference
- Firewall best practice discussion
- Microsoft Patch Tuesday - January 2010 - "Aged Cheese" Edition
- Microsoft Patch Tuesday - February 2010 - "From Microsoft with Love" Edition
- Microsoft Patch Tuesday - March 2010 - "It Won't Happen To Me" Edition