April, 2012

Today we released 6 security bulletins. Four have a maximum severity rating of Critical with the other two addressing Important class vulnerabilities. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

Victim browses to a malicious website that attempts to run a .NET XBAP managed code application on the victim’s system. A security warning will prevent unwitting execution of XBAP applications in the Internet Zone.

Critical

1

Less likely to see significant real-world exploitation due to security warning. Likely to see working proof-of-concept code within next 30 days.

See this SRD blog post for more detail about this security prompt (introduced with MS11-044).

On systems acting as both UAG and UAG DirectAccess server, remote attacker may be able to bypass UAG access checks and gain access to content served by the webserver that they otherwise might not have permission to access. This is a potential information disclosure vulnerability.

Security Update MS12-027 addresses a code execution vulnerability in MSCOMCTL.OCX, the Windows Common Controls ActiveX control. By default, this component is included with all 32-bit versions of Microsoft Office. We’d like to cover the following topics in this blog post:

Limited, targeted attacks leveraging this vulnerability

Mitigations in recent versions of Office to reduce the risk

Extra protections to block all or specific ActiveX controls in Office documents

The new Office 2010 kill bit feature

Limited, targeted attacks leveraging this vulnerability

We list MS12-027 as our highest priority security update to deploy this month because we are aware of very limited, targeted attacks taking advantage of CVE-2012-0158 vulnerability using specially crafted Office documents as exploit vector. The specific samples that we have seen have been RTF files attempting to exploit the vulnerability when opened in either WordPad or Microsoft Word. People who install the MS012-027 patch are protected against CVE-2012-0158 so we recommend applying the update right away. Microsoft Word includes various on-by-default mitigations and optional security hardening features that you might consider enabling. Read on to find out more.

Microsoft Word 2010 Protected View as a mitigation

By default, Microsoft Office 2010 opens documents originating from the Internet and from other potentially unsafe locations in a mode called Protected View. This mode does not allow ActiveX controls to load. If a victim running Office 2010 were to receive an exploit for CVE-2012-0158 over the internet or via email, the victim would need to click the Protected View's "Enable Editing" button before the malicious code would be allowed to run. The screenshots below show two examples of Protected View.

Without going into the details of the previous blog, we’ll just mention once more that Office 2007 and 2010 editions have a dedicated panel for ActiveX controls in Trust Center Settings which allows, in its safest configuration, to completely disable all controls embedded in documents or to prompt a warning dialog when a document tries to use certain type of controls as showed by the following picture.

Disabling specific embedded ActiveX controls with Office kill bit

The ActiveX kill bit feature has proven an effective measure in reducing the attack surface of Internet Explorer during the past years and so Microsoft Office has introduced this feature in a similar way. Office 2007 honors the Internet Explorer kill bit list. Office 2010 takes this a step further by blocking ActiveX controls from the Internet Explorer list and also allowing users to independently control through the registry which COM objects will not be able to run (Office 2010 COM kill bit). If the kill bit is set for the same ActiveX control in both locations, Office and Internet Explorer, and there is a conflict between the two settings, the Office COM kill bit has precedence. The location for setting the Office 2010 COM kill bit in the registry is HKLM/Software/Microsoft/Office/Common/COM Compatibility/{CLSID}, where CLSID is the class identifier of the COM object. To enable the Office COM kill bit for a specific control, first you need to add a registry key with the CLSID of the ActiveX control to block (NOTE: don’t forget the { } parenthesis!) and then add a value of 0x00000400 to the Compatibility Flags REG_DWORD.

Documents containing embedded controls will still be opened by Microsoft Office (some content of the document will be available and visible), however any blocked ActiveX control will not be loaded and will show up in the Office application as showed in the following picture:

The first option described in this blog (Trust Center settings) provides a general and very effective measure against attacks similar to the one observed for CVE-2012-0158, however this configuration needs to be carefully evaluated before wide adoption on corporate networks because it may block the execution of Office documents and applications with embedded ActiveX controls (e.g. an Excel spreadsheet using listbox control for selection). Organizations that have a highly restrictive security environment and concerns about ActiveX controls may consider deploying this setting via group policy or registry.

On the other hand, the second option described today (Microsoft Office 2010 COM kill bit) offers to users and organizations a more selective way to control which embedded ActiveX controls can be trusted and loaded from documents. An organization seeking to block a limited set of untrusted controls without having legacy problems with existing applications may find more useful deploying selective kill-bit configurations instead of using the general “disable all” option discussed earlier.

One of the security bulletins released today, MS12-025, addresses a code execution vulnerability in the .NET Framework. To exploit the vulnerability, an attacker would build a malicious XBAP application and lure victims to a malicious website serving the XBAP.

The good news is that a zero-click “driveby” style attack is no longer possible from the Internet on workstations where MS11-044 (published June 2011) has been installed. MS11-044 introduced an additional security prompt for all XBAP’s encountered from the Internet Zone. A redacted example is pictured below:

We recommend not allowing XBAP’s to run unless you know and trust the Publisher listed in the security dialog. The security bulletin outlines steps to disable XAML browser applications in Internet Explorer on a per-zone basis if you do not need to use this functionality.