Yesterday, the MSRC released Microsoft Security Advisory 979352 alerting customers to limited, sophisticated attacks targeting Internet Explorer 6 customers. Today, samples of that exploit were made publicly available.
Before we get into the details I want to make one thing perfectly clear. The attacks we have seen to date, including the exploit released publicly, only affect customers using Internet Explorer 6. As discussed in the security advisory, while newer versions of Internet Explorer are affected by this vulnerability, mitigations exist that make exploitation much more difficult. We would like to share a little more information about both the vulnerability and the exploits we have seen to help you understand the risk to your organization.
Risk, by platform
Newer versions of Internet Explorer and later Windows releases are at reduced risk to the exploit we have seen due to platform mitigations explained in the blog post below. (Note: Server platforms are omitted from this table because browsing is less likely from Servers.)
|Windows 2000||Windows XP||Windows Vista||Windows 7|
|Internet Explorer 6||Exploitable||Exploitable (current exploit effective for code execution)||N/A|
(Vista ships with IE7)
(Windows 7 ships with IE 8)
|Internet Explorer 7||N/A|
(IE 7 will not install on Windows 2000)
|Potentially exploitable (current exploit does not currently work due to memory layout differences in IE 7)||IE Protected Mode prevents current exploit from working.||N/A|
(Windows 7 ships with IE 8)
|Internet Explorer 8||N/A|
(IE 8 will not install on Windows 2000)
|DEP enabled by default on XP SP3 prevents exploit from working.||IE Protected Mode + DEP enabled by default prevent exploit from working.||IE Protected Mode + DEP enabled by default prevent exploit from working.|
As you can see, the client configuration currently at risk is Windows XP running IE6. We recommend users of IE6 on Windows XP upgrade to a new version of Internet Explorer and/or enable DEP. Users of other platforms are at reduced risk. We also recommend users of Windows XP upgrade to newer versions of Windows.
More information about the vulnerability
Ways to block Code Execution
The vulnerability is present in Internet Explorer 6, Internet Explorer 7, and Internet Explorer 8. All versions may crash after opening the attack code. However, there are a number of ways to limit the attack to an IE crash and prevent attacker code execution.
- Disable code executing from random locations of freed memory. Data Execution Prevention (DEP) prevents the execution of code from pages of memory that are not explicitly marked as executable. DEP is a supported feature on Windows XP Service Pack 2 and higher, Windows Server 2003 Service Pack 2 and higher, and all versions of Windows Vista, Windows Server 2008, and Windows 7. Some platforms enable DEP by default (see below). You can read more about DEP in this blog here and here. You can enable DEP on Windows XP and Windows Vista by clicking the Microsoft Fix It button below. (DEP is enabled by default for Internet Explorer 8 running on XP Service Pack 3, Windows Vista Service Pack 1 and higher, and Windows 7, so you do not need to use the “Microsoft Fix It” for those configurations.)
Note on enabling DEP for Windows Vista
The security advisory lists steps to enable DEP for Internet Explorer 7. To enable DEP on Windows Vista, be sure to run Internet Explorer as an Administrator (Right-click, and then select “Run as Administrator”). After enabling DEP, close the Internet Explorer session and re-launch Internet Explorer to browse with DEP enabled. The option will be grayed-out if you are not running Internet Explorer as an Administrator.
If you enable DEP on Windows Vista using the Microsoft Fix It, you will not see the Internet Explorer user interface change. However, after restarting Internet Explorer, you can use a tool like Process Explorer to verify that DEP is enabled. The Internet Explorer user interface displays value of a registry key while the Microsoft Fix It enables DEP by using an appcompat shim.
Big thanks to Chengyun Chu for his exploit analysis and risk assessment help. And thanks to Rob Hensing for the DEP research and FixIt4Me MSI help. Thanks to Fermin J. Serna for the vulnerability analysis. Lots of people at Microsoft are working on this, thanks everybody.
– Jonathan Ness, MSRC Engineering
*Posting is provided “AS IS” with no warranties, and confers no rights.*