BackgroundAs a part of the July security bulletin, Microsoft yesterday released an update to mitigate a vulnerability in the “Microsoft Video” ActiveX control. This control contained a stack-based buffer overflow which could be exploited by a malicious web page.
If you haven’t yet done so, please make sure you’ve installed the latest updates from WindowsUpdate to help keep your system secure.
The Microsoft Video control should not have been marked as safe because it wasn’t intended for use within the browser. Rather than updating the control itself, Microsoft decided to block misuse of the control via a killbit. Killbits are simple registry flags that instruct the browser not to load the specified control. One advantage of killbits is that they can easily be set with a simple registry modification, and a “FixIt Script” that set this killbit was available on July 6th. You can learn more about the killbit mechanism over on the SRD Blog (Part 1, Part 2, Part 3).
ActiveX Mitigations by IE Version
The Video ActiveX vulnerability was extremely serious for IE6 users because that browser version provides no protection against this exploit unless the killbit is applied.
In contrast, IE7 users had some protection against exploitation of this vulnerability. IE7 includes the ActiveX Opt-in feature which disables most ActiveX controls (including this one) by default. IE7 users on Vista also benefit from Protected Mode, which helps prevent the installation of malicious software, even in the event that an exploit results in code execution.
Beyond Protected Mode and ActiveX Opt-in, IE8 users benefitted from additional protections that help to mitigate vulnerabilities like this one. IE8 includes the per-site ActiveX feature, which extends ActiveX Opt-in by preventing controls that are permitted to run on one site from running automatically on other sites. More importantly in this case, DEP/NX memory protection is enabled by default for IE8 users on Windows XP SP3, Windows Vista SP1+, and Windows 7. DEP/NX helps to foil attacks by preventing code from running in memory that is marked non-executable. DEP/NX, combined with other technologies like Address Space Layout Randomization (ASLR), make it harder for attackers to successfully exploit certain types of memory-related vulnerabilities, including this one.
Security is a Journey
Unfortunately, attackers are always on the lookout for vulnerable code, and Microsoft is currently investigating a vulnerability recently discovered in the Microsoft Office Web Components (OWC) ActiveX controls. Until an update is available, users can help prevent exploitation of the vulnerability by running the FixIt Script that killbits the vulnerable OWC controls.
No Easy Answers
When talking to customers, I’m often asked: “ActiveX controls often have problems. Why not release a version of Internet Explorer without ActiveX?”
It’s a reasonable question, and it goes back to my point that “security is usually easy, it’s the tradeoffs that are hard.” End-users or IT administrators can easily disable ActiveX in all versions of IE in just a few seconds: click Tools > Internet Options > Security > Custom Level… and change the “Run ActiveX controls and plug-ins” setting to “Disable.” Alternatively, IE7 and IE8 users can launch Internet Explorer in No Add-ons mode using the Start Menu shortcut. Unfortunately, many sites depend on the rich capabilities provided by add-on technologies like ActiveX, and those sites will not work as well, or at all, if ActiveX is disabled. Users and administrators can more tactically disable unwanted controls using Manage Add-ons or Group Policy, reducing attack surface as much as possible.
While we continue to evangelize best-practices for developing secure add-ons, we strongly encourage users and organizations to upgrade to IE8. IE8 offers a robust set of mitigations against exploitation of vulnerable controls, helping keep your systems secure.
Thanks for reading!