Security Research & Defense

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

Security Research & Defense

  • MS14-019 – Fixing a binary hijacking via .cmd or .bat file

    Command (.cmd) and batch (.bat) files can be directly provided as input to the CreateProcess as if it is an executable. CreateProcess uses the cmd.exe automatically to run the input .cmd or .bat.

     

    Today, with the bulletin MS14-019 we are fixing a vulnerability, where in particular scenario it is possible to hijack the cmd.exe with a copy present in the attacker controlled current working directory (CWD) of an affected application.

     

    The typical attack vector for this vulnerability is same as the DLL hijacking, i.e., via opening an application specific file in a WebDav/SMB share invoking the targeted application automatically because of file association. The targeted application will be vulnerable only if they ever do CreateProcess on .cmd or .bat file irrespective of where the file is located. That means attacker need not control the .cmd or .bat file. Another important thing for exploiting this vulnerability, is that the application should set the directory from where the associated file was opened as its CWD.

     

    As such we are not aware of any application that is affected by this vulnerability. But we understand the security issue this vulnerability can pose to some of the applications, so we are addressing this as an important severity bulletin.

     

    The way we are fixing this issue is to always invoke the system version of the cmd.exe for the input .cmd or .bat file during process creation. This fix could affect applications which does CreateProcess on .bat or .cmd file directly and depend on a different version of the cmd.exe other than the one present in Sytem directory by copying them in either application directory or CWD. Such applications should pass fully qualified path to the version of cmd.exe as input while performing CreateProcess, and pass .cmd or .bat as input parameters.

     

    Applications passing just cmd.exe to the CreateProcess to run the .cmd or .bat as input could also be vulnerable for similar binary hijacking. This bulletin is not to address such vulnerable usage since it is application specific problem as they are not passing fully qualified system path to cmd.exe. Such application should fixed to pass fully qualified cmd.exe path or just passing .cmd or .bat file as input.

     

    - Swamy Shivaganga Nagaraju, MSRC engineering team

  • Assessing risk for the April 2014 security updates

    Today we released four security bulletins addressing 11 unique CVE’s.  Two bulletins have a maximum severity rating of Critical while the other two have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

     

    Bulletin Most likely attack vector Max Bulletin Severity Max exploitability Likely first 30 days impact Platform mitigations and key notes

    MS14-017

    (Word)

    Victim opens a malicious RTF or DOC/DOCX file. Critical 1 Likely to continue to see RTF and DOC based exploits for CVE-2014-1761. Addresses vulnerability described by Security Advisory 2953095, an issue under targeted attack.

    MS14-018

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days.

    MS14-020

    (Publisher)

    Victim opens malicious Publisher (.PUB) file. Important 1 While we may see reliable exploits developed within the next 30 days, unlikely to see widespread exploitation due to limited deployment of Publisher.

    MS14-019

    (Windows File Handling)

    Attacker places malicious .bat and/or .cmd file on a network share from which a victim launches an application that calls CreateProcess in an unsafe manner.  Similar attack vector as DLL preloading. Important 1 While this is an exploitable vulnerability, we have historically not seen widespread exploitation of this type of vulnerability. More details about this vulnerability in this SRD blog post today.

     

    - Jonathan Ness, MSRC engineering team

  • Security Advisory 2953095: recommendation to stay protected and for detections

    Today, Microsoft released Security Advisory 2953095 to notify customers of a vulnerability in Microsoft Word. At this time, we are aware of limited, targeted attacks directed at Microsoft Word 2010.

    This blog will discuss mitigations and temporary defensive strategies that will help customers to protect themselves while we are working on a security update. This blog also provides some preliminary details of the exploit code observed in the wild.

     

    Mitigations and Workaround

    The in the wild exploit takes advantage of an unspecified RTF parsing vulnerability combined with an ASLR bypass, which depends by a module loaded at predictable memory address.

    First, our tests showed that EMET default configuration can block the exploits seen in the wild. In this case, EMET’s mitigations such as “Mandatory ASLR” and anti-ROP features effectively stop the exploit. You can find more information about EMET at http://www.microsoft.com/emet. The exploit code seems to target Word 2010 and it deeply relies on the specific ASLR bypass mentioned. We were glad to see in our tests that this exploit fails (resulting in a crash) on machines running Word 2013, due to the ASLR enforcement introduced for this product.

    In addition to EMET mitigations, users may consider to apply stronger protections by blocking the root cause of the issue with one of the following suggested workarounds:

    • disable opening of RTF files;

    • enforce Word to open RTF files always in Protected View in Trust Center settings.

    To facilitate deployment of the first workaround, we are providing a Fix it automated tool. The Fix it uses Office’s file block feature and adds few registry keys to prevent opening of RTF files in all Word versions. After the Fix it is installed, opening RTF file will result in the following message:

     


    If blocking RTF files is not an option, enterprise could enforce “Open selected file types in Protected View” instead of “Do not open selected file types” in Trust Center settings. The “Protected View” mode in Office 2010/2013 does not allow ActiveX controls to load. This will mitigate the attack we observed. Once the workaround is enabled, Word will prompt the Protected View gold bar, but will still allow the preview of the document.


    Enterprise admins may also consider to make their own custom protection using Trust Center features of Office instead of the Fix it, since these settings can be managed and deployed through GPO. For more details, please refer to: http://office.microsoft.com/en-us/word-help/what-is-file-block-HA010355927.aspx#_File_Block_settings.

     

     

    Theoretical Outlook attack vector

    There is a theoretical Outlook attack vector for RTF vulnerabilities through the preview pane. The reduced functionality of the preview pane makes this attack vector extremely hard to carry, and to date we have never seen exploits leveraging this mechanism.

     

    Technical details of the exploit

    The attack detected in the wild is limited and very targeted in nature. The malicious document is designed to trigger a memory corruption vulnerability in the RTF parsing code. The attacker embedded a secondary component in order to bypass ASLR, and leveraged return-oriented-programming techniques using native RTF encoding schemes to craft ROP gadgets. The structure of the malicious document and the individual blocks is described in the picture below.

    When the memory corruption vulnerability is triggered, the exploit gains initial code execution and in order to bypass DEP and ASLR, it tries to execute the ROP chain that allocates a large chunk of executable memory and transfers the control to the first piece of the shellcode (egghunter). This code then searches for the main shellcode placed at the end of the RTF document to execute it.


    One peculiar aspect of the main shellcode is the fact that it employs multiple consecutive layers of decryption and well-known anti-debugging tricks, such as test of debugging flags an, RDTSC timing checks and jump-hops over hooks, possibly to defeat automated sandbox, analysis tools and researchers. The shellcode has also been programmed with a special date-based deactivation logic. In fact, it parses the content of “C:\Windows\SoftwareDistribution\ReportingEvents.log” file and it scans all the available Microsoft updates installed on the machine. The shellcode will not perform any additional malicious action if there are updates installed after April, 8 2014. This means that even after a successful exploitation with reliable code execution, after this date the shellcode may decide to not drop the secondary backdoor payload and simply abort the execution. When the activation logic detects the correct condition to trigger, the exploit drops in the temporary folder a backdoor file named ‘svchost.exe’ and runs it. The dropped backdoor is a generic malware written in Visual Basic 6 which communicates over HTTPS and relies on execution of multiple windows scripts via WScript.Shell and it can install/run additional MSI components.

     

    Detection and indicators for defenders

    We are providing a good list of IOCs (Indicator of Compromise) hoping to facilitate defensive efforts and to help security vendors and professionals to stay protected from this specific attack. The remote C&C server used by the current backdoor in the file uses encrypted SSL traffic with a static self-signed certificate that can be easily detected.

     

     YARA RULE (RTF)

    rule SA2953095_RTF
    {
       meta:
         description = "MS Security Advisory 2953095"

     
       strings:
        $badHdr   = "{\\rt{"
        $ocxTag   = "\\objocx\\"
        $mscomctl = "MSComctlLib."
        $rop      = "?\\u-554"

       condition:
        filesize > 100KB and filesize < 500KB
        and $badHdr and $ocxTag and $mscomctl and #rop>8

     SAMPLE HASHES

    Filename: %TEMP%\svchost.exe

    MD5: af63f1dc3bb37e54209139bd7a3680b1
    SHA1: 77ec5d22e64c17473290fb05ec5125b7a7e02828

     C&C SERVER AND 
     PROTOCOL

    C&C Server:
    h**ps://185.12.44.51 Port: 443

    NOTE: on port 80 the C&C host serves a webpage mimicking the content of “http://www.latamcl.com/” website


    GET request example:
    h**ps://185.12.44.51/[rannd_alpa_chars].[3charst]?[encodedpayload]


    User-Agent string:
    “Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64;2*Uuhgco}%7)1”

     C&C SSL CERTIFICATE
     (self-signed)

    Issuer:
        CN=*
        O=My Company Ltd
        S=Berkshire
        C=NW
     NotBefore: 1/1/2013 3:33 AM
     NotAfter: 1/1/2014 3:33 AM

    Public Key Length: 1024 bits
    Public Key: UnusedBits = 0

        0000  30 81 89 02 81 81 00 dc  72 fc af 8f 51 de 2d 27
        0010  3e de ad 21 ae 25 11 b6  b0 6e ce 6d 79 e4 d3 81
        0020  4e 73 11 44 51 63 09 3b  1c e7 79 1f 85 82 94 c1
        0030  e1 f1 83 b3 1c 6d 53 58  28 07 b5 80 86 30 51 2d
        0040  78 c0 48 e8 b2 8d fb 84  e1 d1 59 ff d5 4e 1f 8f
        0050  ff 60 44 56 6b 7b 4d 72  42 d6 da 6a 4c d4 6b 7d
        0060  f1 68 4d 2c 62 58 53 e7  cd cc a1 a4 a2 7a 29 7d
        0070  63 eb 42 30 af 24 eb 20  4c 86 f5 9e 6f 48 1c bd
        0080  28 aa 47 13 4b cc 53 02  03 01 00 01

    Cert Hash(md5): f0 82 aa f8 16 0e 83 8c 20 d7 95 f0 9d d2 01 57
    Cert Hash(sha1): df 72 40 fb 9b cd 53 12 eb a5 f9 c2 dd e7 a2 9a 1d c8 f3 55

     CRASH INDICATORS

    Faulting application name: WINWORD.EXE,
    version: 14.0.7113.5001, time stamp: 0x52866c04
    Faulting module name: unknown,
    version: 0.0.0.0, time stamp: 0x00000000
    Exception code: 0xc0000005
    Fault offset: 0x40002???
    Faulting process id: n/a
    Faulting application start time: n/a
    Faulting application path: C:\Program Files\Microsoft Office\Office14\WINWORD.EXE
    Faulting module path: unknown 

     

     REGISTRY INDICATORS

    Registry key added:
    HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\Windows Startup Helper=”%windir%\system32\wscript.exe %TEMP%\[malicious.vbs]”

    Service name (possibly) created:
    “WindowsNetHelper” 
     

     

    - Chengyun Chu and Elia Florio, MSRC Engineering

     

  • When ASLR makes the difference

    We wrote several times in this blog about the importance of enabling Address Space Layout Randomization mitigation (ASLR) in modern software because it’s a very important defense mechanism that can increase the cost of writing exploits for attackers and in some cases prevent reliable exploitation. In today’s blog, we’ll go through ASLR one more time to show in practice how it can be valuable to mitigate two real exploits seen in the wild and to suggest solutions for programs not equipped with ASLR yet.

     

    Born with ASLR

    ASLR mitigation adds a significant component in exploit development, but we realized that sometimes a single module without ASLR loaded in a program can be enough to compromise all the benefits at once. For this reason recent versions of most popular Microsoft programs were natively developed to enforce ASLR automatically for every module loaded into the process space. In fact Internet Explorer 10/11 and Microsoft Office 2013 are designed to run with full benefits of this mitigation and they enforce ASLR randomization natively without any additional setting on Win7 and above, even for those DLLs not originally compiled with /DYNAMICBASE flag. So, customers using these programs have already a good native protection and they need to take care only of other programs potentially targeted by exploits not using ASLR.

     

    ASLR effectiveness in action

    Given the importance of ASLR, we are taking additional efforts to close gaps when ASLR bypasses arise in security conferences from time to time or when they are found in-the-wild used in targeted attacks. The outcome of this effort is to strength protection also for previous versions of Microsoft OS and browser not able to enforce ASLR natively as IE 10/11 and Office 2013 can do. Some examples of recent updates designed to break well-known ASLR bypasses are showed in the following table.

    MS BULLETIN

    ASLR BYPASS

    REFERENCE

    MS13-063 

    LdrHotPatchRoutine

    Ref: http://cansecwest.com/slides/2013/DEP-ASLR%20bypass%20without%20ROP-JIT.pdf

    Reported in Pwn2Own 2013, works only for Win7 x64 

    MS13-106 

    HXDS.DLL (Office 2007/2010)

    Ref: http://www.greyhathacker.net/?p=585

    Seen used in-the-wild with IE/Flash exploits
    (CVE-2013-3893, CVE-2013-1347,
    CVE-2012-4969, CVE-2012-4792)


    MS14-009 

    VSAVB7RT.DLL (.NET)

    Ref: http://www.greyhathacker.net/?p=585

    Seen used in-the-wild with IE exploits
    (CVE-2013-3893)


    We were glad to see the return of these recent ASLR updates in two recent attacks: the Flash exploit found in February (CVE-2014-0502) in some
    targeted attacks and a privately reported bug for IE8 (CVE-2014-0324) just patched today. As showed from the code snippets below, the two exploits would not have been effective against fully patched machines with MS13-106 update installed running Vista or above.

     

     

    Exploit code for CVE-2014-0502 (Flash)

    Unsuccessful attempt of ASLR bypass using HXDS.DLL fixed by MS13-106.

    NOTE: the code attempts also a second ASLR bypass based on Java 1.6.x

     

    Exploit code for CVE-2014-0324 (IE8)

    Unsuccessful attempt of ASLR bypass using HXDS.DLL fixed by MS13-106.


    Solutions for non-ASLR modules

    The two exploit codes above shows another important lesson: even if Microsoft libraries are compiled natively with ASLR and even if we work hard to fix known ASLR gaps for our products, there are still opportunities for attackers in using third-party DLLs to tamper the ASLR ecosystem. The example of Java 1.6.x is a well-known case: due to the popularity of this software suite and due to the fact that it loads an old non-ASLR library into the browser (MSVCR71.DLL), it became a very popular vector used in exploits to bypass ASLR. In fact, security researchers are frequently scanning for popular 3rd party libraries not compiled with /DYNAMICBASE that can allow a bypass; the following list is just an example of few common ones.

     

    3rd PARTY ASLR BYPASS

    REFERENCE

    Java 1.6.x (MSVCR71.DLL)

     Very common ASLR bypass used in-the-wild for multiple CVEs

     NOTE: Java 1.7.x uses MSVCR100.DLL which supports ASLR

    DivX Player 10.0.2

    Yahoo Messenger 11.5.0.228

    AOL Instant Messenger 7.5.14.8

     Ref: http://www.greyhathacker.net/?p=756 
     (not seen in real attacks)

     

    DropBox

     Ref:http://codeinsecurity.wordpress.com/2013/09/09/installing-dropbox-prepare-to-lose-aslr/

     (not seen in real attacks)

     

    veraport20.Veraport20Ctl

    Gomtvx.Launcher

    INIUPDATER.INIUpdaterCtrl

     Ref: KISA report http://boho.or.kr/upload/file/EpF448.pdf

     (seen in-the-wild with CVE-2013-3893)

     

     

    As noted at beginning of this blog, Internet Explorer 10/11 and Office 2013 are not affected by ASLR bypasses introduced by 3rd party modules and plugins. Instead, customers still running older version of Internet Explorer and Office can take advantage of two effective tools that can be used to enforce ASLR mitigation for any module:

    Conclusions

    ASLR bypasses do not represent vulnerabilities, since they have to be combined with a real memory corruption vulnerability in order to allow attackers to create an exploit, however it's nice to see that closing ASLR bypasses can negatively impact the reliability of certain targeted attacks. We encourage all customers to proactively test and deploy the suggested tools when possible, especially for old programs commonly targeted by memory corruption exploits. We expect that attackers will continue increasing their focus and research on more sophisticated ASLR bypasses which rely on disclosure of memory address rather than non-ASLR libraries.

     

    - Elia Florio, MSRC Engineering

     

  • Assessing risk for the March 2014 security updates

    Today we released five security bulletins addressing 23 unique CVE’s. Two bulletins have a maximum severity rating of Critical while the other three have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

    Bulletin Most likely attack vector Max Bulletin Severity Max Exploit-ability Likely first 30 days impact Platform mitigations and key notes
    MS14-012

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. Addresses vulnerability described by Security Advisory 2934088, an issue under targeted attack.
    MS14-013

    (DirectShow)

    Victim browses to a malicious webpage. Critical 3 Unlikely to see reliable exploits developed within next 30 days. Addresses single double-free issue in qedit.dll, reachable via a malicious webpage.
    MS14-014

    (Silverlight)

    Attacker combines this vulnerability with a (separate) code execution vulnerability to execute arbitrary code in the browser security context. Important n/a No chance for direct code execution with this vulnerability. This vulnerability does not result in code execution directly. However, it is a component attackers could use to bypass ASLR.
    MS14-015

    (Kernel mode drivers)

    Attacker running code at low privilege runs exploit binary to elevate to SYSTEM. Important 1 Likely to see reliable exploits developed within next 30 days.
    MS14-016

    (Security Account Manager)

    Attacker able to make API calls to security account manager password API able to brute-force password guessing attempts without triggering account lockout policy. Important n/a No chance for direct code execution with this vulnerability. Attacker must authenticate before calling the affected API. After authenticating, the attacker can choose to guess either their own or other user's password without risk of lockout.

    - Jonathan Ness, MSRC engineering team

  • Announcing EMET 5.0 Technical Preview

    Today, we are thrilled to announce a preview release of the next version of the Enhanced Mitigation Experience Toolkit, better known as EMET. You can download EMET 5.0 Technical Preview here. This Technical Preview introduces new features and enhancements that we expect to be key components of the final EMET 5.0 release. We are releasing this technical preview to gather customer feedback about the new features and enhancements. Your feedback will affect the final EMET 5.0 technical implementation. We encourage you to download this Technical Preview, try it out in a test environment, and let us know how you would like these features and enhancements to show up in the final version. If you are in San Francisco, California, for the RSA Conference USA 2014, please join us at the Microsoft booth (number 3005) for a demo of EMET 5.0 Technical Preview and give us feedback directly in person.  Several members of the EMET team will be demonstrating at the Microsoft booth for the entire Conference.

    As mentioned, this Technical Preview release implements new features to disrupt and block the attacks that we have detected and analyzed over the past several months. The techniques used in these attacks have inspired us with new mitigation ideas to disrupt exploitation and raise the cost to write reliable exploits. The EMET 5.0 Technical Preview also implements additional defensive mechanisms to reduce exposure from attacks.

    The two new features introduced in EMET 5.0 Technical Preview are the Attack Surface Reduction (ASR) and the Export Address Table Filtering Plus (EAF+). Similar to what we have done with EMET 3.5 Technical Preview, where we introduced a new set of mitigations to counter Return Oriented Programming (ROP), we are introducing these two new mitigations and ask for your feedback on how they can be improved. Of course, they are a “work in progress.” Our goal is to have them polished for the final version of EMET 5.0.

    Let’s see in detail what these two new mitigations do, and the reasoning that led us to their implementation.

    Attack Surface Reduction

    In mid-2013, we published a Fix it solution to disable the Oracle Java plug-in in Internet Explorer. We received a lot of positive feedback and a number of suggestions on how we could improve the Fix it. The most recurring suggestion we received was to allow the Oracle Java plug-in on intranet websites, which commonly run Line-of-Business applications written in Java, while blocking it on Internet Zone websites. In addition to that Java-related customer feedback, we have also seen a number of exploits targeting the Adobe Flash Player plug-in. For example, the RSA breach was enabled by an Adobe Flash Player exploit embedded inside a Microsoft Excel file and a number of targeted attacks have been carried out by Adobe Flash Player exploits embedded in Microsoft Word documents, as described by Citizen Lab. We decided to design a new feature that can be used to mitigate similar situations and to help to reduce the attack surface of applications. We call this feature Attack Surface Reduction (ASR), and it can be used as a mechanism to block the usage of a specific modules or plug-ins within an application. For example, you can configure EMET to prevent Microsoft Word from loading the Adobe Flash Player plug-in, or, with the support of security zones, you can use EMET to prevent Internet Explorer from loading the Java plug-in on an Internet Zone website while continuing to allow Java on Intranet Zone websites.

    The example below shows ASR in action, preventing Microsoft Word from launching an Adobe Flash Player file embedded in the document. By default, EMET 5.0 Technical Preview comes pre-configured to block certain plug-ins from being loaded by Internet Explorer, Microsoft Word and Microsoft Excel. The feature is fully configurable by changing two registry keys that list the names of the plug-ins to block, and, if supported, the security zones that allow exceptions. For more details on how to configure ASR please refer to the EMET 5.0 Technical Preview user guide.

    EAF+

    We also added new capabilities to the existing Export Address Table Filtering (EAF). EAF+ consolidates protection of lower-level modules and prevents certain exploitation techniques used to build dynamic ROP gadgets in memory from export tables. EAF+ can be enabled through the “Mitigation Settings” ribbon. When EAF+ is enabled, it will add the following additional safeguards over-and-above the existing EAF checks:

    • Add protection for KERNELBASE exports in addition to the existing NTDLL.DLL and KERNEL32.DLL

    • Perform additional integrity checks on stack registers and stack limits when export tables are read from certain lower-level modules

    • Prevent memory read operations on protected export tables when they originate from suspicious modules that may reveal memory corruption bugs used as “read primitives” for memory probing

    For example, the third protection mechanism in the list above mitigates the exploitation technique developed in Adobe Flash Player used in some recent Internet Explorer exploits (CVE-2013-3163 and CVE-2014-0322), where the attacker attempted to build ROP gadgets by scanning the memory and parsing DLL exports using ActionScript code. Exploits for these vulnerabilities are already blocked by other EMET mitigations. EAF+ provides another way to disrupt and defeat advanced attacks. The screenshot below shows the exploit for CVE-2014-0322 in action on Internet Explorer protected by EMET 5.0 Technical Preview with only EAF+ enabled.

    Other improvements

    This Technical Preview enables the “Deep Hooks” mitigation setting. We have been working with third-party software vendors whose products do not run properly with Deep Hooks enabled. We believe these vendors have resolved the application compatibility issues that previously existed with Deep Hooks enabled. We enable Deep Hooks in the Technical Preview to evaluate the possibility of having this setting turned on by default in the final EMET 5.0 release because it has proven to be effective against certain advanced exploits using ROP gadgets with lower level APIs. We have also introduced some additional hardening to protect EMET’s configuration when loaded in memory, and fixed several application compatibility issues including a common one that involves Adobe Reader and the “MemProt” mitigation.

    Acknowledgments

    We’d like to thank Spencer J. McIntyre from SecureState, Jared DeMott from Bromium Labs, along with Peleus Uhley and Ashutosh Mehra from the Adobe Security team for their collaboration on the EMET 5.0 Technical Preview.

    We are excited for this Technical Preview and we hope that the additions are as valuable for our customers as they are for us. We invite you to install and give EMET 5.0 Technical Preview a try; we look forward to hearing your feedback and suggestions on how to enhance the new features that we have introduced. We would also welcome any suggestions for additional new features you’d like to see included in the final version of EMET 5.0. We greatly value the feedback we receive, and we want to build a product that not only provides additional protection to systems but is also easy to use and configure. We then invite you all to download EMET 5.0 Technical Preview and drop us a line!

    • The EMET Team

  • Fix it tool available to block Internet Explorer attacks leveraging CVE-2014-0322

    Today, we released Security Advisory 2934088 to provide guidance to customers concerned about a new vulnerability found in Internet Explorer versions 9 and 10. This vulnerability has been exploited in limited, targeted attacks against Internet Explorer 10 users browsing to www.vfw.org and www.gifas.asso.fr. We will cover the following topics in this blog post:

    • Platforms affected
    • Steps you can take to stay safe
    • More details about the vulnerability
    • More details about the Fix It tool

    Platforms Affected

    As described in Security Advisory 2934088, both Internet Explorer 9 and Internet Explorer 10 contain the vulnerable code. However, we have not seen any exploit code capable of triggering the vulnerability on Internet Explorer 9. The chart below may help explain the risk by platform:

      Windows XP
    Server 2003
    Windows Vista
    Server 2008
    Windows 7
    Server 2008 R2
    Windows 8
    Server 2012
    Windows 8.1
    Server 2012 R2
    Internet Explorer 6 Not vulnerable n/a n/a n/a n/a
    Internet Explorer 7 Not vulnerable Not vulnerable n/a n/a n/a
    Internet Explorer 8 Not vulnerable Not vulnerable Not vulnerable n/a n/a
    Internet Explorer 9 n/a Vulnerable,
    not under attack
    Vulnerable,
    not under attack
    n/a n/a
    Internet Explorer 10 n/a n/a Under attack Under attack n/a
    Internet Explorer 11 n/a n/a Not vulnerable n/a Not vulnerable

    Steps you can take to stay safe

    Any of the following three protection mechanisms will protect you from exploits we have seen that leverage this vulnerability for code execution:

    1 – Upgrade to Internet Explorer 11

    2 – Install the Enhanced Mitigation Experience Toolkit (EMET)

    3 – Install the Fix it workaround tool

    Upgrading to Internet Explorer 11 is the best way to stay safe from exploit attempts targeting this vulnerability.

    The Enhanced Mitigation Experience Toolkit (EMET) is also an effective way to block the targeted attacks we have analyzed. This particular exploit explicitly checks for EMET and refuses to run on any system where EMET is installed. However, even with the exploit’s EMET check removed, the default configuration of EMET blocks the attack. In this particular case, EMET’s EAF and Anti-Detour features block the exploit in the default EMET configuration. With EMET’s “Deep Hooks” feature enabled, the MemProt, StackPivot, and CallerCheck features each independently are capable of blocking this exploit. We are pleased to see EMET continuing to provide protection for a significant portion of memory corruption exploits today. On that note, we found that in the second half of 2013, all in-the-wild exploits that we encountered that have leveraging memory corruption for code execution were blocked by EMET! We recommend that all customers install this tool. Watch next week for an announcement at the RSA Conference about the future of EMET.

    The third, and likely easiest way to protect yourself from attempts to exploit the vulnerability, is to install the Fix it workaround tool released in today’s advisory. You can refer to Knowledge Base Article 2934088 for complete details but simply clicking through the “Fix It” installer from the following link will protect your system from attempts to exploit the vulnerability:

    Installing the Fix it does not require a reboot but administrative privileges on the system are required. The Fix it installation will be effective on any Internet Explorer 9 or Internet Explorer 10 system where the most recently-released security update (MS14-010) has already been installed. More specifically, the appcompat shim is enabled for the Internet Explorer process where mshtml.dll is one of the following four versions: 9.0.8112.16533, 9.0.8112.20644, 10.0.9200.16798, or 10.0.9200.20916. The eventual security update that addresses this vulnerability will ship with an incremented mshtml.dll version number, thereby automatically obsoleting this Fix it.

    You can read more about previous instances of this temporary workaround technique at http://blogs.technet.com/b/srd/archive/tags/fixit/. Fix its have been a popular mitigation technique with our customers to cover the gap between the time when an exploit appears and the time when a final, comprehensive, fully-tested security update is available for wide distribution. The last instance of a Fix It tool to address an Internet Explorer vulnerability (addressed by MS13-080) was installed on 23 million computers. The most recent security-related Fix it solution mitigated an Office vulnerability that was subsequently addressed by MS13-096. That Fix It solution was installed on 57 million computers. We mention these numbers with the hope of giving you confidence that a number of your IT Pro peers are using Fix it solutions to protect their enterprise network.

    More details about the vulnerability and exploit

    CVE-2014-0322 describes an mshtml.dll use-after-free vulnerability involving the CMarkup object being accessed after it has been freed. As described above, this vulnerability is present in both Internet Explorer 9 and Internet Explorer 10 but exploits we have seen target only 32-bit Internet Explorer 10. The exploit was explained in greater detail on the FireEye security blog. To recap, it uses Javascript to trigger the use-after-free condition and then uses Flash to convert a write primitive into a read/write primitive that enables DEP and ASLR to be bypassed. The primitive conversion happens by redirecting a write based on a freed object’s data (which has now been reallocated by the attacker) to corrupt a size field inside a Flash object. The corrupted size field in the Flash object is used to read and write outside of the object’s boundary, allowing discovery of module addresses in Internet Explorer’s Address Space. We are not aware of any elevation of privilege or sandbox escape vulnerability being used to “break out” of the Internet Explorer Protected Mode sandbox. Therefore, even after the exploit gains code execution, it still needs a non-trivial element to result in a persistent compromise of the computer.

    More details about the Fix it tool

    The Fix it redirects execution of two functions, mshtml!CMarkup::InsertElementInternal and mshtml!CMarkup::InsertTextInternal, to the code introduced by the appcompat shim. Similar changes are made in both functions. Let’s take a closer look at mshtml!CMarkup::InsertElementInternal:

    0:020> u mshtml!Cmarkup::InsertElementInternal
    MSHTML!CMarkup::InsertElementInternal:
    e9d3d2a500      jmp     MSHTML!SZ_HTMLNAMESPACE+0xf (66bb43c7) // we redirect execution
    
    0:020> u 66bb43c7
    MSHTML!SZ_HTMLNAMESPACE+0xf:
    60              pushad	//save registers
    8bc8            mov     ecx,eax	//move the this* pointer to ecx
    e818468bff      call    MSHTML!CMarkup::CLock::CLock+0x2 (664689e7)	//call into the code where we AddRef() on this CMarkup object
    61              popad	//restore our registers
    55              push    ebp  //execute the code we overwrote in the jump to this shim
    8bec            mov     ebp,esp
    e91c2d5aff      jmp     MSHTML!CMarkup::InsertElementInternal+0x5 (661570f4)	//jump back to the next instruction after the our redirection point
    

    Similar to the Fix it solution for CVE-2013-3893, the shim leverages slack space near the end of the mshtml.dll’s .text section. Astute readers may notice that the appcompat shim does not introduce any code to reduce the reference count on the CMarkup object. Said another way, the appcompat shim introduces a memory leak.  The memory is restored when an IE tab (process) is terminated. This minor side effect of the workaround tool is harmless and of course it won’t be present in the final comprehensive security update for this vulnerability.

    Acknowledgements

    Thanks to Richard Van Eeden, Axel Souchet, Chengyun Chu, and Elia Florio for the help triaging this vulnerability and help building the Fix it workaround tool.

    Conclusion

    Please let us know if you have any questions about the risk posed by this vulnerability, the exploits we have seen leveraging the vulnerability for code execution, or mitigation opportunities available to protect your systems. You can email us at secure@microsoft.com with [SRD] in subject line. Or if you plan to attend the RSA Conference in San Francisco, CA next week, feel free to stop by the Microsoft Booth #3005 to talk to us in person. We’re looking forward to announcing EMET news on Tuesday morning.

    - Neil Sikka, MSRC Engineering (@neilsikka)

  • Assessing risk for the February 2014 security updates

    Today we released seven security bulletins addressing 31 unique CVE’s. Four bulletins have a maximum severity rating of Critical while the other three have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

    Bulletin Most likely attack vector Max Bulletin Severity Max Exploit-ability Likely first 30 days impact Platform mitigations and key notes
    MS14-010

    (Internet Explorer)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. Addresses both memory corruption vulnerabilities and elevation of privilege vulnerabilities in a single package.
    MS14-011

    (VBScript)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. The single CVE addressed by this bulletin is included in MS14-010 for IE9 users. Customers with IE9 installed need not deploy MS14-011.
    MS14-007

    (DirectWrite)

    Victim browses to a malicious webpage. Critical 1 Likely to see reliable exploits developed within next 30 days. Internet Explorer is vector to this vulnerability in DirectWrite.
    MS14-005

    (MSXML)

    Victim browses to a malicious website to be exposed to this information leak vulnerability. Important 3 Vulnerability first seen as ASLR bypass mechanism in targeted attacks during November 2013. May see attacks again begin using this again as details emerge. As discussed in the SRD and FireEye blogs during November 2013, this vulnerability was used along with another vulnerability in active attacks. The MS13-090 security update completely blocked all attacks described by those blog posts.
    MS14-009

    (.NET Framework)

    Most likely to be exploited vulnerability involves attacker initiating but not completing POST requests to ASP.NET web application, resulting in resource exhaustion denial of service. Important 1 Resource exhaustion attacks involving CVE-2014-0253 already in progress in the wild. CVE-2014-0253 addresses resource exhaustion “Slowloris” attack.

    CVE-2014-0257 addresses sandbox escape vulnerability invoving com objects running code out-of-process.

    CVE-2014-0295 addresses the vsab7rt.dll ASLR bypass described at http://www.greyhathacker.net/?p=585.

    MS14-008

    (Forefront Protection for Exchange)

    Code is unlikely to be reachable. However, if attackers do find a way, it would involve a malicious email message being processed by the Forefront Protection for Exchange service. Critical 2 Unlikely to see exploits developed targeting this vulnerability. While this vulnerability’s attack vector appears attractive (email), the vulnerability is unlikely to be reachable. It was discovered internally by code analysis and we have not been successful in developing a real-world vulnerability trigger. We address it via security update out of an abundance of caution.
    MS14-006

    (IPv6)

    Attacker on the same subnet as victim (IPv6 link-local) sends large number of malicious router advertisements resulting in victim system bugcheck. Important 3 Denial of service only. This bugcheck is triggered by a watchdog timer on the system, not due to memory corruption. Affects Windows RT, Windows Server 2012 (not R2), and Windows 8 (not 8.1).

    - Jonathan Ness, MSRC

  • Assessing risk for the January 2014 security updates

    Today we released four security bulletins addressing six CVE’s. All four bulletins have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

    Bulletin Most likely attack vector Max Bulletin Severity Max exploit-ability rating Likely first 30 days impact Platform mitigations and key notes
    MS14-002

    (NDProxy, a kernel-mode driver)

    Attacker able to run code at a low privilege level inside an application sandbox exploits this vulnerability to elevate privileges to SYSTEM. Important 1 Likely to continue seeing Adobe PDF exploits leveraging this vulnerability to elevate privileges outside sandbox. All exploits we have analyzed for this vulnerability attempt to exploit an already-patched Adobe Reader vulnerability, CVE-2013-3346. This Adobe vulnerability was addressed via a September 11, 2013 Adobe security update.

    Addresses vulnerability described by security advisory 2914486.

    MS14-001

    (Word)

    Victim opens malicious Office document. Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS14-003

    (win32k.sys, a kernel-mode driver)

    Attacker running code at low privilege runs exploit binary to elevate to SYSTEM. Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS14-004

    (Microsoft Dynamics AX)

    Attacker able to authenticate to Dynamics server could cause denial-of-service condition preventing it from servicing other client requests. Important n/a Denial of service only, not usable for code execution.  

    - Jonathan Ness, MSRC engineering

  • Software defense: mitigating common exploitation techniques

    In our previous posts in this series, we described various mitigation improvements that attempt to prevent the exploitation of specific classes of memory safety vulnerabilities such as those that involve stack corruption, heap corruption, and unsafe list management and reference count mismanagement. These mitigations are typically associated with a specific developer mistake such as writing beyond the bounds of a stack or heap buffer, failing to correctly track reference counts, and so on. As a result, these mitigations generally attempt to detect side-effects of such mistakes before an attacker can get further along in the exploitation process, e.g. before they gain control of the instruction pointer.

    Another approach to mitigating exploitation is to focus on breaking techniques that can apply to many different classes of memory safety vulnerabilities. These mitigations can have a broader impact because they apply to techniques that are used further along in the process of exploiting many vulnerabilities. For example, once an attacker has gained control of the instruction pointer through an arbitrary vulnerability, they will inherently need to know the address of useful executable code to set it to. This is where well-known mitigations like Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) come into play – both of which have been supported on Windows for many releases now. When combined, these mitigations have proven that they can make it very difficult to exploit many classes of memory safety vulnerabilities even when an attacker has gained control of the instruction pointer.

    In recent years, attackers have been increasingly forced to adapt to exploiting vulnerabilities in applications that make use of a broad range of mitigations, including DEP and ASLR. As our previous blog post explains, there are scenarios where both DEP and ASLR can be bypassed, and it is no surprise that attackers have been increasingly focused on improving their ability to do so. Likewise, attackers have placed greater interest on finding classes of vulnerabilities, such as use after free issues, that can grant them more flexibility when attempting to develop an exploit. In light of these trends, we focused a significant amount of attention in Windows 8 and Windows 8.1 on improving the robustness of mitigations that break exploitation techniques that apply to many classes of vulnerabilities. In particular, this blog post will cover some of the noteworthy improvements that have been made to ASLR, such as eliminating predictable address space mappings, increasing the amount of entropy that exists in the address space, and making it more difficult to disclose address space information where possible.

    Force ASLR

    For compatibility reasons, executable images (DLLs/EXEs) must indicate their desire to be randomized by ASLR through the /DYNAMICBASE flag provided by the Visual C++ linker.  If an executable image has not been linked with /DYNAMICBASE, the Windows kernel will attempt to load the image at its preferred base address.  This can cause the executable to reliably load at a predictable location in memory.  While this limitation of ASLR on Windows is by design, real-world exploits for software vulnerabilities have become increasingly reliant on executable images that have not enabled support for ASLR. 

    To generically mitigate this issue, an application running on Windows 8 (or Windows 7 with KB 2639308 installed) can elect to enable a security feature known as Force ASLR.  When enabled, this feature forces all relocatable images to be randomized when they are loaded by the application, including those images which have not been linked with /DYNAMICBASE.  This is designed to prevent executable images from being loaded at a predictable location in memory.  If desired, an application can also elect to prevent non-relocatable images from being loaded.

    Since the Force ASLR feature will cause executable images to be randomized that have not enabled support for ASLR, there is a risk that a compatibility problem may be encountered.  In addition, the method used to forcibly relocate executable images that have not been built with /DYNAMICBASE can have a performance impact due to decreased page sharing. This is because Force ASLR essentially mimics the behavior of a base address collision and thus may incur a memory cost due to copy-on-write. As such, the Force ASLR feature is not enabled by default for applications running on Windows 8.  Instead, applications must explicitly enable this feature.

    The Force ASLR feature has been enabled by default for critical applications such as Internet Explorer 10+, Microsoft Office 2013, and Windows Store applications.  This means an attacker attempting to exploit vulnerabilities accessible through these applications will not be able to rely on non-randomized executable images. For example, our recent security update to enable ASLR for HXDS.DLL would not appreciably impact the security posture of applications that enable Force ASLR because this non-ASLR DLL would already get randomized. Going forward, attackers will most likely need to rely on a vulnerability-specific address space information disclosure when exploiting applications that completely enable ASLR or that make use of Force ASLR.

    Bottom-up and Top-down Randomization

    Virtual memory allocations that are made by an application can have their base address assigned in one of three ways: bottom-up, top-down, or based.  The bottom-up method searches for a free region starting from the bottom of the address space (e.g. VirtualAlloc default), the top-down method searches starting from the top of the address space (e.g. VirtualAlloc with MEM_TOP_DOWN), and the based method attempts to allocate memory at a supplied base address (e.g. VirtualAlloc with an explicit base).  In practice, the majority of the memory that is allocated by an application will use the bottom-up allocation method, and it is rare to see applications use the based method for allocating memory.

    Prior to Windows 8, bottom-up and top-down allocations were not randomized by ASLR.  This meant that allocations made through functions like VirtualAlloc and MapViewOfFile had no entropy and could therefore be placed at a predictable location in memory (barring non-deterministic application behavior).  While certain memory regions had their own base randomization, such as heaps, stacks, TEBs, and PEBs, all other bottom-up and top-down allocations were not randomized.

    Starting with Windows 8, the base address of all bottom-up and top-down allocations is explicitly randomized.  This is accomplished by randomizing the address that bottom-up and top-down allocations start from for a given process.  In this way, fragmentation within the address space is minimized while also realizing the benefits of randomizing the base address of all memory allocations that are not explicitly based.

    For compatibility reasons, applications must indicate that they support bottom-up and top-down randomization.  An application can do this by linking their EXE with /DYNAMICBASE.

    High Entropy Randomization

    One of the major differences between 64-bit and 32-bit applications on Windows is the size of the virtual address space that is made available to a process.  64-bit applications whose EXE is linked with the /LARGEADDRESSAWARE flag receive 8 TB in Windows 8 (128 TB in Windows 8.1) of virtual address space whereas 32-bit applications only receive 2 GB by default.  The limited amount of address space available to 32-bit applications places practical constraints on the amount of entropy that can be applied by ASLR when randomizing the location of memory mappings.  Since 64-bit applications do not suffer from these limitations by default, it is possible to significantly increase the amount of entropy that is used by ASLR.  The ASLR implementation in Windows 8 takes full advantage of this opportunity by enabling high degrees of entropy for 64-bit applications.  Providing higher degrees of entropy can further decrease the reliability of exploits written by an attacker and also makes it less likely that an attacker will be able to correctly guess or brute force an address.

    High Entropy Bottom-up Randomization

    This feature introduces 1 TB of variance into the address that bottom-up allocations start from.  This equates to 24 bits of entropy, or a 1 in 16,777,216 chance of guessing the start address correctly.  Since heaps, stacks, and most other memory regions are allocated bottom-up, this has the effect of making traditional address space spraying attacks impractical (such as heap and JIT spraying).  This is because systems today do not have enough memory available to spray the amount that would be needed to achieve even small degrees of reliability.  In addition, executable images that are randomized by the Force ASLR feature receive high degrees of entropy as a result of the high entropy bottom-up randomization feature being enabled for an application. As a result, exploits for vulnerabilities in 64-bit applications that rely on address space spraying will first need to disclose the address at least one bottom-up allocation in order to determine where data may have been placed relative to that address.

    For compatibility reasons, this feature is disabled by default and must be enabled on a per-application basis.  This is because some 64-bit applications have latent pointer truncation issues that can surface when dealing with pointers above 4 GB (significant bits set beyond bit 31).  64-bit applications that enable this feature are guaranteed to receive memory addresses that are above 4 GB when allocating bottom-up memory (unless insufficient address space exists above 4 GB).  64-bit applications can enable support for this feature by linking their EXE with the /HIGHENTROPYVA linker flag provided by Visual Studio 2012. This flag is enabled by default for native applications when building with Visual Studio 2012 and beyond.

    High Entropy Top-down Randomization

    This feature introduces 8 GB of variance into the address that top-down allocations start from.  This equates to 17 bits of entropy, or a 1 in 131,072 chance of guessing the start address correctly.  64-bit processes automatically receive high degrees of entropy for top-down allocations if top-down randomization has been enabled (which is controlled by whether the EXE linked with /DYNAMICBASE).   

    High Entropy Image Randomization

    Prior to Windows 8, 64-bit executable images received the same amount of entropy that was used when randomizing 32-bit executable images (8 bits, or 1 in 256 chance of guessing correctly).  The amount of entropy applied to 64-bit images has been significantly increased in most cases starting with Windows 8:

    • DLL images based above 4 GB: 19 bits of entropy (1 in 524,288 chance of guessing correctly)
    • DLL images based below 4 GB: 14 bits of entropy (1 in 16,384 chance of guessing correctly). 
    • EXE images based above 4 GB: 17 bits of entropy (1 in 131,072 chance of guessing correctly).
    • EXE images based below 4 GB: 8 bits of entropy (1 in 256 chance of guessing correctly).

    The reason that entropy differences exist due to the base address of an image is again for compatibility reasons.  The Windows kernel currently uses the preferred base address of an image as a hint to decide if the image supports being based above 4 GB.  Images that are based below 4 GB may not have been tested in scenarios where they are relocated above 4 GB and therefore may have latent pointer truncation issues.  As such, the Windows kernel makes a best-effort attempt to ensure that these images load below 4 GB.  Because of these constraints, the vast majority of 64-bit EXEs and DLLs in Windows 8 and Windows 8.1 have been based above 4 GB to ensure that they benefit from the highest possible degrees of entropy. 64-bit images produced by the Visual C++ tool chain also base images above 4 GB by default.

    Address Space Information Disclosure Hardening

    The effectiveness of ASLR is inherently dependent on an attacker being unable to discover the location of objects in memory.  In some cases, an attacker can leverage a vulnerability in a program to disclose information about the address space layout of a process.  For example, an attacker could use a vulnerability to read memory that they would not normally be able to access and thereby discover the address of a DLL in memory.  While the mechanics of disclosing address space information are typically dependent on the application and vulnerability that are being exploited, there are some general approaches that attackers have identified.  In Windows 8, we have taken steps to eliminate and destabilize known address space information disclosure vectors, although these changes have by no means resolved the general problem posed by address space information disclosures.

    Image pointers removed from SharedUserData

    Windows uses an internal data structure known as SharedUserData to efficiently communicate certain pieces of information from the kernel to all processes on a system.  For efficiency and compatibility reasons, the memory address that SharedUserData is located at is consistent across all processes on a system and across all versions of Windows, including Windows 8 (0x7ffe0000).  Since Windows XP Service Pack 2, this memory region has contained pointers into a system DLL (NTDLL.DLL) that have been used to enable efficient system call invocation, among other things.  The presence of image pointers at a known-fixed location in memory was noted as being useful in the context of certain types of address space information disclosures.  In Windows 8 (and now prior versions with MS13-063 installed), all image pointers have been removed from SharedUserData to mitigate this type of attack. The removal of these pointers effectively mitigated a DEP/ASLR bypass that was later disclosed which affected versions of Windows prior to Windows 8 (involving LdrHotPatchRoutine).

    Predictable fixed memory mappings eliminated

    Ensuring that all forms of memory allocation have some base level of entropy has the effect of eliminating what would otherwise be predictable memory mappings in the address space. In some cases, an attacker may be able to leverage a vulnerability to read the contents of arbitrary locations in memory. In these cases, the attacker must be able to predict or discover the address of the object that they wish to read from (typically via heap spraying). The improvements that have been made to ASLR in Windows 8 have made it more difficult for attackers to do this reliably, particularly on 64-bit. As a result, any address space information disclosure that relies on reading from a specified location in memory will generally be more difficult and less reliable on Windows 8. It should be noted, however, that the size of the 32-bit address space places practical constraints on the impact of this, particularly in cases where an attacker is able to fill a large portion of the address space with desired content.

    Kernel address space information access restrictions

    While the previous sections highlighted improvements that were made to ASLR for user mode applications, we also made investments in Windows 8.1 into hardening the Windows kernel against disclosing kernel address space information to lesser privileged user mode processes. The majority of these improvements focused on restricting low integrity processes from accessing certain system and process information classes that intentionally expose kernel address space information. In addition, certain kernel addresses were removed from the shared desktop heap and hypervisor-assisted restrictions were added to limit the exposure of kernel addresses via instructions that can be used to query the GDT/IDT descriptor table base addresses. As a result of these improvements, sandboxed applications such as Internet Explorer 11, Microsoft Office 2013, and Windows Store apps are all prevented from discovering addresses through these interfaces. This means it will be more difficult for attackers to exploit local kernel vulnerabilities as a means of escaping these sandboxes.

    Conclusion

    The improvements that have been made to ASLR in Windows 8 and Windows 8.1 have addressed various limitations that attackers have been taking advantage when exploiting vulnerabilities. As a result of these improvements, we anticipate that attackers will continue to be increasingly reliant on address space information disclosures as a means of bypassing ASLR. Forcing attackers to rely on information disclosures has the effect of adding another costly check box to the conditions that attackers need to satisfy when exploiting memory safety vulnerabilities in modern applications.

    - Matt Miller