Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Yesterday we heard reports of a commercially available exploit that bypasses DEP. This exploit was made available to a limited number of major security vendors (Antivirus, IDS, and IPS vendors) and government CERT agencies. We wanted to use this opportunity to give an overview of current customer risk related to this DEP bypass.
Real-world attacks so far still only effective against Internet Explorer 6
We have seen an increase in attacks attempting to exploit the vulnerability detailed in Security Advisory 979352. However, all attacks we have seen so far still target Internet Explorer 6 - this is also confirmed by the attack samples our Microsoft Active Protections Program (MAPP) partners have sent in.
While we have not seen real-world attacks for any other platform, we have seen researchers poking at other platforms and have seen the following:
State-of-the-art of attacker research on various platforms
Here’s the current state-of-the-art on each platform:
Other mitigations (besides DEP)
We have discussed DEP at length in this blog. As you can see in the table above, two other mitigations help prevent or limit the impact of attacks on later platforms.
Out-of-band update coming tomorrow
We’ll be releasing a comprehensive, well-tested security update tomorrow morning PST to address this vulnerability. In the meantime, we hope this information helps you assess risk and protect your environment.
Thanks Matt Miller and John Lambert for help with the ASLR arithmetic and other feedback.
Update Jan 20, 2010: Updated "less than 1%" to "1%". Thanks reader Larry for catching arithmetic error.
Update Jan 22, 2010: Updated to reflect new understanding of the commercially-available, limited distribution exploit on IE8 / XP SP3. Also removed formula behind the theoretical 1% ASLR success chance. The formula was off by a fraction of a percentage point and the math to describe it would be difficult to explain. The chance is approximately 1.1%.
- Jonathan Ness, MSRC Engineering
*Posting is provided "AS IS" with no warranties, and confers no rights.*
The new Internet Explorer security vulnerability described by Microsoft Security Advisory 979352 has received a lot of interest over the past few days. The Internet Explorer team is hard at work preparing a comprehensive security update to address the vulnerability and the MSRC announced today that as soon as the update is ready for broad distribution, it will be released.
We have heard several questions from customers attempting to protect their environment in the meantime. Most questions have been around Data Execution Prevention (DEP), a mitigation we discussed in our previous blog post. To help you better understand DEP specifically as it relates to Internet Explorer 8, we have prepared the following video where I discuss some of the higher level concepts:
Which versions of Internet Explorer have enabled DEP by default?
Hardware-enforced DEP is enabled by default for Internet Explorer on the following platforms:
· Internet Explorer 8 on Windows XP Service Pack 3,
· Internet Explorer 8 on Windows Vista Service Pack 1 and later,
· Internet Explorer 8 on Windows Server 2008, and
· Internet Explorer 8 on Windows 7.
Windows 2000 has no support for hardware-enforced DEP. Windows XP Service Pack 2, Windows Server 2003 Service Pack 1, and Windows Vista support hardware-enforced DEP do not have the SetProcessDEPPolicy API that Internet Explorer 8 uses to enable DEP.
How can users of other versions of Windows or Internet Explorer enable DEP?
Windows XP SP2 and Windows Vista RTM users can click this button to launch an MSI that will enable DEP for Internet Explorer.
How can you determine whether hardware-enforced DEP is available with your hardware?
Microsoft KB 912923 describes in more detail how to determine that hardware DEP is available and configured on your computer.
What is the difference between "Software DEP" and hardware-enforced DEP (/NX)?
"Software DEP" is unfortunately really not DEP at all. "Software DEP" is just another name for /SAFESEH [MSDN link]. Unfortunately, /SAFESEH is not an effective mitigation for this vulnerability. Only hardware-enforced DEP disrupts exploits attempting to abuse this vulnerability.
Does IE’s DEP behave differently in the Intranet Zone (as compared to the Internet Zone)?
DEP itself is enabled per process, regardless of application-layer content. However, a well-known DEP bypass is used by attackers to mark pages executable using .NET classes. IE8 does not allow these .NET class to load in the Internet Zone. In the Intranet Zone, the .NET classes are allowed to load. Therefore, an attacker capable of hosting content on your corporate network may be able to bypass DEP and successfully exploit this vulnerability.
We hope that helps answer questions you may have had about DEP.
*This posting is provided "AS IS" with no warranties, and confers no rights*
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.)
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.
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.
MS10-001 addresses a vulnerability (CVE-2010-0018 ) in the LZCOMP de-compressor for Microtype Express Fonts. This blog aims to answer some questions regarding the updates we’ve made in this area.
What is the issue?t2embed.dll improperly performs bounds-checking on lengths which are decoded from the LZCOMP bit-stream. This made it possible for a copy loop to violate the intended working buffer.
Is the EOT functionality reachable through 3rd party code?Yes, the t2embed library provides EOT functionality that can be used by 3rd party code. Many 3rd parties import t2embed for their font rendering, though some may choose to implement their own font rendering.
Why an Exploitability Index rating of 2?The Exploitability Index rating or 2 is due to the low likelihood of successful exploitation. Hurdles exist around heap preparation and predictability, heap data corruption, and a race condition to get an exception handler making successful exploitation unlikely.
What is the likelihood of successful exploitation?Due to the nature of bounds-checking performed in t2embed on 32-bit systems XP and later, the only buffer+index combinations which would pass the old checks will point into address 0x80000000 and above. Because these regions cannot be accessed while running at IOPL 3, the process will crash (Access Violate) and the attempt to run arbitrary code would fail.
On Windows 2000, this vulnerability could be abused to leverage code execution. On 32-bit platforms post Windows 2000, improper memory access would commonly be observed in the form of a Read Access Violation at address 0x80000000 or above, though the memory layout on /3GB-enabled systems could be manipulated to compromise the integrity of the hosting process. Stability (Denial of Service) implications exist on these systems when /3GB is not enabled (default), whereas /3GB-enabled systems run a risk of code execution, though no known attack vectors exist in Microsoft products.
Third party products which are (A) large address aware (http://msdn.microsoft.com/en-us/library/wz223b1z(VS.80).aspx), (B) consume the t2embed, and are (C) running on a /3GB-enabled system should be considered exploitable.
On 64-bit platforms, improper memory access would commonly be observed in the form of a Read Access Violation at a kernel mode address which would affect application stability (Denial of Service) with no threat of code-execution.
Here is a table to represent the exploitation scenarios described above:
The Windows 2000 severity rating of critical was chosen due to the vulnerable code being exposed through client applications that can render EOT fonts in a way that does not require user interaction/notification. (such as Microsoft Internet Explorer, Microsoft Office PowerPoint, and Microsoft Office Word)
What are the attack vectors?Remote attack vectors are all in user-mode:
How do I protect myself?The best option for protecting against this vulnerability is to apply the update for MS10-001.
As stated in a previous SRD blog post, another option is to disable support for parsing/loading embedded fonts in IE. The side effect of this approach is that it will cause web sites which make use of embedded font technology to fail to render properly.
What is /3GB and how can I tell if /3GB is enabled on my system?/3GB is a switch and it allows 32-bit systems to benefit from 3GB of addressable memory versus the default 2GB of memory. More information on /3GB can be found here. You can check to see whether you have /3GB enabled on your system by typing the following command in a shell:
Windows Boot Manager
description Windows Boot Manager
Windows Boot Loader
description Microsoft Windows Vista
Note the increaseuserva variable. If unset (or set to 2048), you do not have /3GB enabled. If this value is set to 3072 (as seen here) you have /3GB enabled.
What is LZCOMP?LZCOMP is a compression algorithm variation of the LZ77 theme. A great explanation of LZCOMP and how it differs from LZ77 can be found here.
Where does the LZCOMP de-compressor component reside on my system?The LZCOMP de-compressor exists within the t2embed dynamically linked library. It commonly resides in %SystemRoot%\System32 and is imported by programs such as Office and Internet Explorer.
How does this Fonts vulnerability differ from the previous Fonts vulnerability addressed by MS09-065?This vulnerability exists in a user-mode component (t2embed.dll) whereas the previous Fonts vulnerability (MS09-065) addressed a kernel-mode component (win32k.sys).
I’d like to thank Matt Miller for general guidance, Bruce Dang and Robert Hensing from the MSRC Engineering Team for their efforts on this release.
-Brian Cavenah, MSRC Engineering