Internet Explorer Mitigations for ATL Data Stream Vulnerabilities

IE security update MS09-034 implements two defense-in-depth measures intended to mitigate the threat of attacks which attempt to exploit the Microsoft Active Template Library (ATL) vulnerabilities described in Security Advisory 973882 and MS09-034. We would like to explain these mitigations in more detail.

ATL persisted data checks

The first mitigation is a change to modify how ATL-based controls read persisted data by detecting specific call patterns that are problematic. One such example is the call pattern that led to the MSVidCtl.dll exploit addressed by MS09-032, one of the security updates released on July 14th. Furthermore, the mitigation addresses the ATL vulnerabilities addressed by, and described in, MS09-035.

The change is on by default for all affected platforms that have installed MS09-034, and will block all known ATL vulnerabilities for any controls loaded in Internet Explorer (even those not created by Microsoft.) We anticipate limited application compatibility problems with this defense in depth change. For this reason we encourage customers to test and deploy MS09-034 right away to block potential attacks on vulnerable controls.

Controlling the usage of specific interfaces (potential application compatibility impact)

MS09-034 also introduces a second defense-in-depth mitigation on the vulnerable platforms. This mitigation is off by default, because it is a “heavy hammer” that prevents the Web Browser control from initializing controls using the IPersistStream* and IPersistStorage interfaces. In essence, this mitigation addresses the ATL vulnerabilities by preventing the overall usage of the potentially dangerous interfaces rather than specific call patterns that occur as those interfaces are exercised.

We encourage application developers that host the Web Browser Control to opt-in to this mitigation using the new FEATURE_RESTRICT_OBJECT_DATA_ATTRIBUTE Feature Control Key.

The FEATURE_RESTRICT_OBJECT_DATA_ATTRIBUTE key is currently off by default because many controls are known to load persisted data using IPersistStream* and IPersistStorage in scenarios which are understood to be by design. Any place where a control is loaded via an OBJECT tag and where the DATA attribute is used in that OBJECT tag is a scenario that this mitigation could potentially impact control functionality and compatibility.

For example, the mitigation could prevent the expected operation of the following OBJECT tag:

<object classid="clsid:…" DATA=”http://fabrikam.com/foo”>

In order to enable this Feature Control Key, follow these steps:

• Open HKLM or HKCU\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl key in the registry.
• Create a subkey for FEATURE_RESTRICT_OBJECT_DATA_ATTRIBUTE, if it doesn’t already exist.
• Add a new REG_DWORD value for a process name, or * to opt-in all processes, and set its value to 1.

As an example, the following registry value opts in to the FEATURE_RESTRICT_OBJECT_DATA_ATTRIBUTE Feature Control for all processes:

HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)
     SOFTWARE
          Microsoft
               Internet Explorer
                    Main
                         FeatureControl
                              FEATURE_RESTRICT_OBJECT_DATA_ATTRIBUTE
                                   * = 0x00000001

Individual controls which have been determined to not be vulnerable to the attack using IPersistStream* and IPersistStorage can opt-out of the mitigation by using a new ActiveX Compatibility Flag DWORD value:

HKEY_LOCAL_MACHINE
     SOFTWARE
          Microsoft
               Internet Explorer
                    ActiveX Compatibility
                         {CLSID of ActiveX control}
                              Compatibility Flags = 0x02000000

Keep in mind that the Compatibility Flags value for any given control is a bit field, so be careful not to blindly overwrite the value or remove it, so as not to erase a Kill-Bit.

You can implement the “heavy hammer” approach described in the earlier example to opt-in all processes with the understanding that certain scenarios and line of business application might break. To help customers more easily turn on the second defense in depth change we are providing the below FixIt packages.

Enable user specific Feature Control Key for all processes (HKCU will be changed)
http://go.microsoft.com/?linkid=9674474

Disable user specific Feature Control Key for all processes (HKCU will be changed)
http://go.microsoft.com/?linkid=9674475

Enable system wide Feature Control Key for all processes (HKLM will be changed)
http://go.microsoft.com/?linkid=9674476

Disable system wide Feature Control Key for all processes (HKLM will be changed)
http://go.microsoft.com/?linkid=9674477

- David Ross, MSRC Engineering

*Posting is provided “AS IS” with no warranties, and confers no rights.*