Today Microsoft revised the Workarounds section of Security Advisory 961051. We wanted to share more detail about the vulnerability and explain the additional workarounds here to help you protect your computers.
Information about the vulnerability
The vulnerability is caused by memory corruption resulting from the way Internet Explorer handles DHTML Data Bindings. This affects all currently supported versions of Internet Explorer. Malicious HTML that targets this vulnerability causes IE to create an array of data binding objects, release one of them, and later reference it. This class of vulnerability is exploitable by preparing heap memory with attacker-controlled data (“heap spray”) before the invalid pointer dereference.
Which workarounds should you apply?
The advisory now lists nine different workaround options. We have been adding additional workarounds with each advisory revision to give you more surgical options to cut off the vulnerable code path. Only IE8 has an option to turn off data binding altogether. So unless you are using IE8, you’ll need to:
- (A) block access to the vulnerable code in MSHTML.dll via OLEDB, protecting against current attacks
- (B) apply the most secure configuration against this specific vulnerability.
Optionally, you may choose to (C) make it much harder to heap spray.
The table below lists what type of protection each advisory workaround provides.
| Workaround | A | B | C |
|---|---|---|---|
| 1. Set Internet and Local intranet security zone settings to “High” to prompt before running ActiveX Controls and Active Scripting in these zones | X | X | |
| 2. Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone | X | X | |
| 3. Disable XML Island Functionality | X | ||
| 4. Restrict Internet Explorer from using OLEDB32.dll with an Integrity Level ACL | X | ||
| 5. Disable Row Position functionality of OLEDB32.dll | X | ||
| 6. Unregister OLEDB32.DLL | X | ||
| 7. Use ACL to disable OLEDB32.DLL | X | ||
| 8. Enable DEP for Internet Explorer 7 on Windows Vista and on Windows Server 2008 | X | ||
| 9. Disable Data Binding support in Internet Explorer 8 | X | X |
Applying a workaround from the (A) column will protect against current attacks but to comprehensively protect against the vulnerability, we recommend that you also apply a workaround from the (B) column.
Why list five different ways to protect against OLEDB data provider attack vector?
Let’s briefly touch on workarounds 3-7, each being a different way to protect against the OLEDB data provider attack vector.
6 & 7 –Unregister or Disable via ACL the OLEDB32.DLL
We listed these workarounds in yesterday’s advisory and they still remain viable options. However, these are two somewhat drastic options. All applications that rely on any part of this DLL will fail to function.
5 - Disable Row Position functionality of OLEDB32.dll
In our investigation, we discovered that disabling a single OLEDB32 COM object is enough to block access to the affected code path. We continue to list workaround options #6 and #7 in the advisory but #5 is actually far preferable because it is as good as either #6 or #7 and less invasive.
4 - Restrict Internet Explorer from using OLEDB32.dll with an Integrity Level ACL
This workaround option is another way to block access to the OLEDB data provider. The great thing about this option is that it blocks access for Internet Explorer only. It will not disrupt stand-alone data access applications. However, it only exists when UAC and IE Protected Mode are both enabled (default configuration) on Windows Vista and Windows Server 2008. We will go into more detail for this option below because it is pretty cool. :)
3 - Disable XML Island functionality
Exploits targeting the OLEDB data provider require msxml3.dll as well as OLEDB32.dll. We initially considered suggesting customers unregister or ACL msxml3.dll to block attempts to exploit the vulnerability. Blocking msxml3.dll system-wide turned out to break lots of stuff. However, disabling only the XML Data Island CLSID is enough to prevent msxml3.dll from loading only for IE for known attacks. Also, from our testing, it appears that not very many websites use the XML Data Island functionality so this is our least intrusive workaround from column A and it works on all supported platforms.
Further information about the Integrity Level ACL workaround
To provide this type of selective protection, the new workaround relies on the fact that, by default, Internet Explorer runs with Protected Mode turned on. This means that the iexplore.exe process runs at a low integrity level. For more information on what this means and how this works, refer to http://msdn.microsoft.com/en-us/library/bb250462.aspx. As mentioned in the article, the integrity mechanism makes it possible to block processes from being able to write to securable objects (such as files) that have a higher integrity level. One thing that the article does not mention, however, is that it is also possible to block a process from being able to read or execute securable objects at a higher integrity level. This is done by applying a special integrity level entry to the Access Control List (ACL) for an object. Later on in this post, we will walk you through how to do this for OLEDB32.DLL such that Internet Explorer cannot read or execute it.
One thing that should be noted about this workaround is that Internet Explorer must be running with Protected Mode turned on. This requires that both Protected Mode and User Account Control (UAC) are enabled (the default setting). You can determine whether or not Protected Mode is enabled by examining the Internet Explorer status bar as is illustrated in the following screenshot:
Enabling the Workaround (only applies to Windows Vista and later operating systems)
To use this workaround you must first create a temporary directory and then copy an inf file from the attached zip file to it. Use the BlockAccess_x86.inf file if the underlying operating system is 32 bit and the BlockAccess_x64.inf file if the underlying operating system is 64 bit. If you are unsure which operating system you are using, you can figure it out by opening the Control Panel and selecting System. Look for the following output in the resulting window.
Once you have the appropriate file copied over, start an elevated Administrator command prompt, navigate the prompt to the temporary directory, and run the following command where <inf> is the name of the file you copied to the directory.
SecEdit /configure /db BlockAccess.sdb /cfg <inf> <inf>
</inf>
After running the command, you should see the following output.
The task has completed successfully.
See log %windir%\security\logs\scesrv.log for detail info.
SecEdit will also create a file called BlockAccess.sdb in the directory it was run from. You can safely delete it and the inf file.
Validating the Workaround
It is possible to use the icacls command to quickly determine whether or not the workaround has been applied. If you are using a 32 bit operating system, you just need to run the following command:
icacls "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"
On the other hand if you are using a 64 bit operating system, you will need to run icacls twice; once for the 32 bit version of OLEDB32.DLL and once for the 64 bit version. The two commands are as follows:
icacls "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"
icacls "%ProgramFiles(x86)%\Common Files\System\Ole DB\oledb32.dll"
Each time you run icacls, search through the output for the following line.
Mandatory Label\Medium Mandatory Level:(NW,NR,NX)
If the line is present and includes both the NR and NX values, the workaround has successfully been applied. However, if either the line is missing, or one of the NR or NX values is missing, the workaround has NOT been successfully applied.
Undoing the Workaround
To undo the workaround, you will once again need to create a temporary directory and copy an inf file from the zip into it. This time you will need to copy UnblockAccess_x86.inf if you are using a 32 bit operating system and UnblockAccess_x64.inf if you are using a 64 bit one. After copying the file, start an elevated Administrator command prompt, navigate to the temporary directory, and run the following command where <inf> is the name of the file you copied to the directory.
SecEdit /configure /db UnblockAccess.sdb /cfg <inf><inf></inf>
You should see the same output as before and similar to last time, you can safely delete the UnblockAccess.sdb and UnblockAccess.inf files.
Let us know if you have any questions.
Update Dec 13, 2008: Added “Disable XML Island Functionality” workaround.
- Andrew Roths, Jonathan Ness, Chengyun (SVRD Bloggers)
*Postings are provided “AS IS” with no warranties, and confers no rights.*