Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

January, 2010

  • Assessing risk of IE 0day vulnerability

    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)
    N/A
    (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

    The vulnerability is an Internet Explorer memory corruption issue triggered by an attacker using JavaScript to copy, release, and then later reference a specific Document Object Model (DOM) element. If an attacker is able to prepare memory with attack code, the reference to a random location of freed memory could result in execution of the attacker’s code.

    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 JavaScript. Microsoft Security Advisory 979352 includes this workaround but we understand that this workaround significantly impacts usability of many Web sites.

    • 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.

    Acknowledgements

    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.*

  • Additional information about DEP and the Internet Explorer 0day vulnerability

    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:

    Get Microsoft Silverlight More listening and viewing options:

    To summarize:

    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.

    Jonathan Ness

    *This posting is provided "AS IS" with no warranties, and confers no rights*

  • MS10-001: Font file decompression vulnerability

    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:

      /2GB not running Large Address Aware Application /3GB not running Large Address Aware Application /2GB running Large Address Aware Application /3GB running Large Address Aware Application
    32-bit XP and newer Denial of Service Denial of Service Denial of Service Chance for Code Execution
    64-bit XP and newer Denial of Service Denial of Service Denial of Service Denial of Service
    Windows 2000 Chance for Code Execution Chance for Code Execution Chance for Code Execution Chance for Code Execution

    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:

    • Malicious fonts (EOT) delivered within files hosted on malicious web sites which are rendered in all versions of Internet Explorer by default.
    • Malicious office documents e-mailed to victims with social engineering to entice the victim to open the document which contains a malformed embedded font which would then be rendered upon opening the Office document (PowerPoint and Word documents are the most likely attack vectors).

    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:

    C:\>bcdedit.exe /v
    
    Windows Boot Manager
    --------------------
    identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
    device                  partition=D:
    description             Windows Boot Manager
    locale                  en-US
    inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
    default                 {4a81cc63-2e99-11de-a190-00188b749f31}
    resumeobject            {4a81cc62-2e99-11de-a190-00188b749f31}
    displayorder            {4a81cc63-2e99-11de-a190-00188b749f31}
    toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
    timeout                 30
    
    Windows Boot Loader
    -------------------
    identifier              {4a81cc63-2e99-11de-a190-00188b749f31}
    device                  partition=C:
    path                    \Windows\system32\winload.exe
    description             Microsoft Windows Vista
    locale                  en-US
    inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
    bootdebug               Yes
    osdevice                partition=C:
    systemroot              \Windows
    resumeobject            {4a81cc62-2e99-11de-a190-00188b749f31}
    nx                      OptIn
    increaseuserva          3072
    debug                   No
    

    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

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

  • Reports of DEP being bypassed

    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:

    • Private proof-of-concept code exploiting IE7 on Windows XP for arbitrary code execution
    • Private proof-of-concept code exploiting IE7 on Windows Vista without DEP enabled for code execution within the Protected Mode sandbox. We are not aware of any proof-of-concept code exploiting Windows Vista with DEP enabled.
    • Commercial, limited distribution proof-of-concept code exploiting IE8 on Windows XP with DEP enabled for arbitrary code execution.

    State-of-the-art of attacker research on various platforms

    Here’s the current state-of-the-art on each platform:

      Windows XP Windows Vista Windows 7
    IE 6 Public exploit code consistently reliable for arbitrary code execution N/A N/A
    IE 7 Private proof-of-concept is likely consistently reliable for arbitrary code execution Private proof-of-concept is likely consistently reliable for limited code execution within the Protected Mode sandbox. N/A
    IE 8 In our testing, the commercially-available, limited distribution exploit does result in successful code execution with DEP enabled. No known proof-of-concept code. Current exploits modified for use on Windows Vista would likely be effective for limited code execution within the Protected Mode sandbox on 1% of exploit attempts. It would result in an Internet Explorer crash for 99% of exploit attempts. Exploits are substantially less reliable due to the presence of ASLR on Windows Vista. No known proof-of-concept code. Current exploits modified for use on Windows 7 would likely be effectively for limited code execution within the Protected Mode sandbox on 1% of exploit attempts. It would result in an Internet Explorer crash for 99% of exploit attempts. Exploits are substantially less reliable due to the presence of ASLR on Windows 7.

    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.

    • Internet Explorer Protected Mode limits the impact of Windows Vista and Windows 7 exploits. Attackers who are able to successfully exploit Internet Explorer on those platforms are stuck in a “sandbox”, potentially able to read data but unable to install programs or change system configuration.
    • Address Space Layout Randomization (ASLR) makes exploiting vulnerabilities more difficult by relocating normally-predictable code locations pseudo-randomly in memory. ASLR re-bases DLL’s to random locations in memory, making ret2libc type attacks unreliable. Due to ASLR we believe exploits for Internet Explorer 8 on Windows Vista or Windows 7 could result in limited code execution for 1% of attempts.

    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.

    Acknowledgements

    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.*