Microsoft is finding themselves under increasing pressure to release fixes for critical vulnerabilities. This week, Microsoft broke from tradition again and opted to release and early fix for a critical Internet Explorer vulnerability. Since we’ve seen other critical vulnerabilities come up before this one, some of which were being exploited in the wild, why the change of policy? One factor that might be influencing this decision is the sudden availability of third-party patches. Back in March, eEye released an unofficial patch for the MSIE createTextRange() flaw which drew criticism and contempt from Microsoft. Windows/IE users were under no pressure to use the patch, but it gave some an alternative to disabling Active Scripting entirely.
This time around, we’re seeing multiple third parties come up with alternative patches that may help some companies while they wait for Microsoft to officially fix a vulnerability. This week the Internet Explorer setSlice vulnerability is being exploited in the wild with more than two weeks before Microsoft possibly releases a patch for it. With this reoccuring trend of critical vulnerabilities going unpatched for “too long”, a group of security professionals has created a new response team called ZERT to help consumers. Determina has also released a patch for the setSlice vulnerability, giving consumers even more choices in helping to mitigate the threat while waiting for Microsoft to patch.
With more and more third party patches available, will it pressure Microsoft to step up and break the monthly patch cycle more often? Will they realize that making patches available for critical vulnerabilities being exploited in the wild, even if not fully tested, is a better option than consumers finding themselves under the control of computer criminals and botnets? After all, we know that Microsoft is perfectly capable of producing fast patches when they think it is a serious issue.
This blog will serve as a dumping ground for browser-based security research and vulnerability disclosure. To kick off this blog, we are announcing the Month of Browser Bugs (MoBB), where we will publish a new browser hack, every day, for the entire month of July. The hacks we publish are carefully chosen to demonstrate a concept without disclosing a direct path to remote code execution. Enjoy!
There are already two Microsoft IE vulnerabilities posted. This should prove to be a fun blog!
p.s. Anyone else have flashbacks to SoD and the HP Bug of the Week? =)
Sure, the news that Microsoft silently patches vulnerabilities made the rounds. But honestly, who was surprised in the least? We’ve all known it is a common practice among many vendors, not just Microsoft. As you may have guessed, the reasoning behind this practice is a commonly heard justification:
“We want to make sure we don’t give attackers any [additional] information that could be used against our customers. There is a balance between providing information to assess risk and giving out information that aids attackers,” Mike Reavey said.
OK, we can buy that up to a certain point. So how about just saying “This patch also fixed X internally discovered vulnerabilities during internal audits.” At least give us an idea just how big the patch really is and help us figure out just how many vulnerabilities are being patched. That doesn’t give the bad guys enough information to act on.
About a week ago I started receiving emails from vendors warning that if the upcoming Internet Explorer patch was installed it would break all of their applications. Some of the emails were fairly detailed and even explained that once the patch was installed there was no going back since it could not be uninstalled. I had not heard of anything prior to the emails but figured this month was going to be extra painful.
When reading the details for MS06-013 it becomes clear real quick that something is a bit off on this one when you get to the Caveats section.
From Microsoft’s website:
Caveats: Microsoft Knowledge Base Article 912812 documents the currently known issues that customers may experience when they install this security update. The article also documents recommended solutions for these issues. For more information, see Microsoft Knowledge Base Article 912812. […] Compatibility Patch – To help enterprise customers who need more time to prepare for the ActiveX update changes discussed in Microsoft Knowledge Base Article 912945 and included in Microsoft Security Bulletin MS06-013, Microsoft is releasing a Compatibility Patch on April 11, 2006. As soon as it is deployed, the Compatibility Patch will temporarily return Internet Explorer to the previous functionality for handling ActiveX controls. This Compatibility Patch will function until an Internet Explorer update is released as part of the June update cycle, at which time the changes to the way Internet Explorer handles ActiveX controls will be permanent. This compatibility patch may require an additional restart for systems it is deployed on. For more information, see Microsoft Knowledge Base Article 917425.
It appears that Microsoft has packaged a non-security update with the “Cumulative Security Update” that is going to change the way ActiveX controls work in order to circumvent a recent patent lawsuit. The spin on this being included in the patch appears to be increased ActiveX security.
The bottom line is that if you want to patch Internet Explorer this month you also are going to have a good chance of breaking quite a few applications as these other change has been packaged with the update. It appears to be impossible to get a patch that just corrects the vulnerabilities. Ah, but there is some hope as Microsoft did release that “Compatibility Patch” that will give you until June to fix everything!
What am I missing here?
Here is a good article that explains the issues.
Microsoft has established a public database to allow Internet Explorer users to report bugs in the Web browser.
To post or view bugs, users must sign up for a Passport account on the Microsoft Connect Web site.
Microsoft plans to allow non-registered users to view reported bugs in a couple of months, according to a post on the Internet Explorer Weblog.
Microsoft is only accepting bug posts for Internet Explorer 7 and future versions.
The last line is curious. I understand a vendor’s motive for not supporting a product it considers old, and not updating it. I even understand a vendor saying “from here on out, no updates, including security updates”. However, MSIE6 will be heavily used for years to come, and will remain a large part of personal and corporate user installations. MSIE6 consists of a lot of code and represents a decade of work from Microsoft. Pointing out bugs in security or functionality should be of interest to them, even if they plan to completely ditch version 6. Such bugs would help them learn more about how the code is used and abused, and help them from making the same mistakes in future releases.
Back on December 8th, 2005, I posted a comment about someone who created an eBay entry for a “Brand new Microsoft Excel Vulnerability”. The vulnerability was never sold via eBay, but may have traded hands through other means. For the most part, this incident faded into the background but I think this was the proverbial pebble thrown into the pond. Jump forward to yesterday, and Microsoft released an advisory covering multiple vulnerabilities in Excel. While chatting with one of the OSVDB manglers, I began to think out loud about why we would see so many Excel vulnerabilities released at once, and I think it became clear.
Remote Code Execution Using a Malformed Range – CVE-2005-4131
Remote Code Execution Using a Malformed File Format – CVE-2006-0028
Remote Code Execution Using a Malformed Description – CVE-2006-0029
Remote Code Execution Using a Malformed Graphic – CVE-2006-0030
Remote Code Execution Using a Malformed Record – CVE-2006-0031
Remote Code Execution Using a Malformed Routing Slip – CVE-2006-0009
Looking back at the original eBay entry, the poster said “all the details were submitted to Microsoft, and the reply was received indicating that they may start working on it. It can be assumed that no patch addressing this vulnerability will be available within the next few months.” The technical details released at the time stated “Microsoft Excel does not perform sufficient data validation when parsing document files. As a result, it is possible to pass a large counter value to msvcrt.memmove() function which causes critical memory regions to be overwritten, including the stack space.”
Note the CVE assignments for each of the vulnerabilities listed above. CVE-2005-4131 covers the eBay Excel 0-day. Shortly after that, we see CVE-2006-00xx assigned for five more Excel vulnerabilities and it is pretty clear what happened. Ollie Whitehouse, Peter Winter-Smith, Dejun, Eyas and Arnaud Dovi (via TP) all probably tried to find more details on the posted 0-day. In doing so, they discovered additional vulnerabilities in Excel and thankfully (for Microsoft) followed a responsible disclosure policy. This turned out to be an interesting byproduct of an amusing eBay listing.