Microsoft Patch Tuesday Roundup - May 2010 - Language Barrier Edition

Microsoft's Language

No, I'm not talking about C# or Visual Basic, I'm referring to Microsoft's very own version of the English language ("Minglish"?). An example of the Microsoft variation on the English language is shown here:

"The vulnerability could allow remote code execution if a user visits a malicious e-mail server."

We've addressed the "could allow" statement in a previous post (for example, changing your shoes “could allow” you to win the lottery). We've also addressed the "remote code" execution and dug into what that really means. In this case, it takes on a slightly different meaning from the traditional remote buffer overflow or client-side attacks. The part that is brand new to the "Minglish" language is "if a user visits a malicious e-mail server". Let me get this straight: you not only have to be running the vulnerable software but must also think to yourself, "Gee, I wonder what a malicious e-mail server looks like? I think I will re-configure my email client to connect to pop3.evilbadguy.com and find out".

Of course, I'm being just a tad facetious. Microsoft seems to soften the impact of the vulnerabilities they disclose each month. This provides us with the opportunity to be creative and explore them together. In the context of MS10-30, here's the "English" version:

1. Public exploit code exists - Microsoft states that this vulnerability was "privately reported" and that "Microsoft had not received any information to indicate that this vulnerability had been publicly used to attack customers and had not seen any examples of proof-of-concept code published when this security bulletin was originally issued". However, the individual who reported this vulnerability released proof-of-concept code to the public. This means that exploits will be written much more quickly and distributed in the wild. I believe this to be even truer of MS10-30 than most other security bulletins because the vulnerability affects Outlook Express, Windows Mail and Windows Live Mail. This software is primarily used by individuals on their home computers, not by those working for a company that has a patch management program in place.
2. "Important" is all about context - What is important to you may not be important to me. At first glance, I noticed that MS10-30 was ranked as "Critical" for Windows XP, but only "Important" for Windows 7. One might think that extra security features in Windows 7 mitigate the vulnerability, which would decrease its impact, but this is not the case. According to the H-Online, "Under Windows 7, the problem is considered less critical than under XP and Vista – however, this is only because Windows 7 users need to manually install the mail applications before their systems become vulnerable." This is preposterous; if this is really true then all Adobe updates (according to Microsoft) could be ranked as "Important" because users have to first download the software.
3. Users will never know that they are visiting a malicious email server - Attackers seeking to exploit this vulnerability will use MiTM techniques to redirect the clients to a mail server that is issuing the commands to exploit the clients. There are several ways to do this, including DNS cache poisoning, arp spoofing/poisoning, or even taking over the layer 3 router and redirecting traffic. For example, in order to get DNS cache poisoning to scale (for a larger botnet, of course), an Internet hosting provider would be targeted. Most subscribers use Outlook Express or Windows Mail because it’s free. An attacker poisons the provider's DNS server, then everyone who makes a connection to an evil POP3/IMAP server becomes compromised.

Everyone Loves Features, Until They Get Exploited

"You can disable ActiveX controls in the 2007 Microsoft Office System using the TrustCenter. Refer to the instructions for how to "Disable all controls without notification" in the Microsoft Office Online article, Enable or disable ActiveX controls in Office documents.

Impact of workaround. Embedded ActiveX controls (such as macros) will not run in Office documents."

Is it so bad to disable macros across the board? Do we need such features in order to use Office products? The ability to embed code inside of a document has plagued the security of most document types lately, including Adobe Reader. As part of the hardening guidelines for your organization, it wouldn’t hurt to evaluate this security control and lean towards disabling macros. Don't we have enough features in Microsoft Office without the ability to embed code within the document?

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-030 - Nessus Plugin ID 46312 (Credentialed Check) - This update fixes the Outlook Express/Windows Mail/Windows Live Mail vulnerability. Since exploit code has been published, users are strongly advised to apply this patch immediately, regardless of whether it is listed as "Important" or "Critical".
• MS10-031 - Nessus Plugin ID 46313 (Credentialed Check) - Fixes the Office Visual Basic ActiveX control problem. While evaluating this patch, I encourage everyone to take a look at your policies regarding allowing macros in Office documents.