Security Research & Defense

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

September, 2013

  • Software Defense Series: Exploit mitigation and vulnerability detection

    Software Defense is a broad topic requiring a multipronged approach including:

    -          the processes and tooling associated with secure development (that we try and encapsulate within the Microsoft SDL),

    -          core OS countermeasures that make exploitation of a given vulnerability more difficult for an attacker,

    -          steps to secure the hardware on which the software runs,

    -          real time analysis of other software on the host such as that performed by Windows Defender…

    All these play a part. Our focus in this series is on the first two of these, more specifically on how the Windows operating system together with the toolchain included in Visual Studio releases together improve the state of Software Defense with respect to exploit mitigation and vulnerability detection.

    Exploitation of memory safety vulnerabilities has been an area of active research, both defensive and offensive, in recent years. In this series we outline by way of examples our approach to improving the quality and resilience of code to such issues, for both Microsoft products and third party code running on Microsoft platforms.

    At a high level there are two tiers of approach, summarized in the preceding paragraph by the words ‘quality’ and ‘resilience’:

    1.       Resilience

    We invest in exploit mitigations that will make any residual bugs in our products:

    • Difficult to exploit – thus driving up the attacker’s cost,
    • Unreliable to exploit – thus minimizing the attacker’s return on investment as an unreliable exploit is more likely to be detected and reported to Microsoft or other security vendors.

    The impact of security science in protecting customers provides some historical data on the impact of past deployment of such mitigations. The value that we place on exploit mitigations is also underlined by our recently announced Mitigation Bypass bounty and BlueHat Defense program. As well as describing recent improvements in exploit mitigation, this series will highlight some of the less obvious challenges that we face during design and development, including:

    -          how a given measure will impact backwards application compatibility.

    -          performance impact in terms of runtime cost, memory overhead and code size.

    The first posts in the series review how successive Windows and VC++ releases have enabled widespread hardening against heap and stack corruption vulnerabilities.

    We will then move on to describe the status of generic exploit mitigations such as DEP/ASLR, aimed directly at frustrating attacker techniques, rather than any specific class of vulnerability.

    Having looked at these generic approaches, the next articles will review far more targeted runtime measures against specific classes of code defects such as reference-counting issues, local elevation of privilege through kernel mode null dereferences and integer overflow bugs.

    2.       Quality

    We will conclude the series by describing some of the capabilities that we’ve developed to statically detect more bugs during development through analysis of source code during compilation, thus enabling many issues to be fixed before a product ships. In particular we will focus on new security-relevant warnings in the latest Visual Studio release and how they can be applied directly in your own apps.

    In order to improve accuracy and minimize noise, such detection techniques are typically highly targeted at very specific code defects: while the scope of protection is therefore limited to a specific bug class, they do however offer the potential of completely eradicating that bug class.

    Balancing scope of applicability with completeness of protection is a theme that we will pick up again in more detail in later articles. We will also discuss trade-offs related to application compatibility and issues raised when considering back-porting new security advances to older platforms.

    Many of the items above, taken on their own, can appear as disparate unrelated improvements. This series is an opportunity to highlight some of the connections and underlying rationale behind the various complementary approaches that we pursue along with the engineering challenges that we have faced along the way. We hope you find it interesting.

     

    MSEC security science team

     

  • CVE-2013-3893: Fix it workaround available

    Today, we released a Fix it workaround tool to address a new IE vulnerability that had been actively exploited in extremely limited, targeted attacks.  This Fix it makes a minor modification to mshtml.dll when it is loaded in memory to address the vulnerability. This Fix it workaround tool is linked from Security Advisory 2887505 that describes this issue.  The exploit we analyzed worked only on Windows XP or Windows 7 running Internet Explorer 8 or 9.  Here are the links to both apply and uninstall the Fix it solution:

    Enable Fix itDisable Fix it

    The Exploit

    The exploit was attacking a Use After Free vulnerability in IE’s HTML rendering engine (mshtml.dll) and was implemented entirely in Javascript (no dependencies on Java, Flash etc), but did depend on a Microsoft Office DLL which was not compiled with ASLR (Address Space Layout Randomization) enabled. This DLL (hxds.dll) is loaded into IE by the HTML href attribute shown below:

    try { location.href = 'ms-help://' } catch (e) { }

    The purpose of this DLL in the context of this exploit is to bypass ASLR by providing executable code at known addresses in memory, so that a hardcoded ROP (Return Oriented Programming) chain can be used to mark the pages containing shellcode (in the form of Javascript strings) as executable. This can be seen by the fact that ALL the gadgets used by the ROP chain were contained in hxds.dll.

    Control over the EIP (x86 Instruction Pointer) was gained by reallocating erroneously freed memory on the Low Fragmentation Heap via maliciously formatted Javascript strings, and then waiting for a Virtual Function to be called on the freed object. The attacker gained control over EIP, and made it point into the heap around address 0x12121212 which contained a ROP chain. Below is the contents of the ROP chain:

    Addr            Data                 Significance
    12121212  51c3b376    //ret
    12121216  51c3b376    //ret
    1212121a  51c3b376    //ret
    1212121e  51c3b376    //ret
    12121222  51c3b376    //ret
    12121226  51c3b376    //ret
    1212122a  51c3b376    //ret
    1212122e  51c3b376    //ret
    12121232  51c3b376    //ret
    12121236  51c3b376    //ret
    1212123a  51c3b376    //ret
    1212123e  51c3b376    //ret
    12121242  51c3b376    //ret
    12121246  51c3b376    //ret
    1212124a  51c3b376    //ret
    1212124e  51c3b376    //ret
    12121252  51c3b376    //ret
    12121256  51c3b376    //ret
    1212125a  51c3b376    //ret
    1212125e  51c3b376    //ret
    12121262  51c3b376    //ret
    12121266  51c3b376    //ret
    1212126a  51c3b376    //ret
    1212126e  51c3b376    //ret
    12121272  51c3b376    //ret
    12121276  51c3b376    //ret
    1212127a  51c3b376    //ret
    1212127e  51c2046e    //pop edi;  ret
    12121282  51be4a41    //xchg eax, esp;  ret                     stack pivot. we call into here
    12121286  51c2046e    //pop edi;  ret
    1212128a  51bd10b8    //VirtualProtect IAT entry in hxds
    1212128e  51c0e455    //mov eax, [edi];  pop edi;  ret          move VirtualProtect address in to eax and waste next ROP chain link
    12121292  51c3b376    //ret
    12121296  51bd71f4    //push eax;  ret                          push VirtualProtect address, and ret into it
    1212129a  121212da    return address after VirtualProtect (Shellcode)
    1212129e  12121212    lpAddress                                 //VirtualProtect(lpAddress = 12121212, dwSize = 00001000,
    121212a2  00001000    dwSize                                    //flNewProtect = 00000040 = PAGE_EXECUTE_READWRITE,
    121212a6  00000040    flNewProtect                              //   lpflOldProtect = 12120a0c)
    121212aa  12120a0c    lpflOldProtect                            //
    

    EMET 4.0

    EMET 4.0 can be used to help protect against the exploit we analyzed that attempts to exploit this vulnerability. The specific mitigations to enable are as follows:

      • Mandatory ASLR
      • ROP
        • Enable MemProt
        • Enable Caller
        • Enable SimExecFlow
        • Enable StackPivot
      • Heap Spray
        • Find the value of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET\iexplore.exe\ *\Internet Explorer\iexplore.exe
        • Open HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET\_settings_\VALUE_FROM_STEP_1\heap_pages
        • Add 0x12121212 to the list

    FixIt

    We also built an appcompat shim as a temporary Advanced Workaround to help protect against attempts to exploit this vulnerability.

    There are only 23 patched bytes in whole Fix it to mitigate the vulnerability. The 23 patched bytes occur in two locations-the caller to redirect execution to the shim code, and the shim code itself. Here is an explanation of the patched bytes and what they do in IE9 running on Windows 7:

    Before Fix it:

    mshtml!CDoc::SetMouseCapture [j:\win7\inetcore\mshtml\src\site\base\ipwnd.cxx @ 3211]:
    8bff            mov     edi,edi
    55              push    ebp
    8bec            mov     ebp,esp
    81eca0000000    sub     esp,0A0h
    53              push    ebx
    8b5d08          mov     ebx,dword ptr [ebp+8]
    56              push    esi
    57              push    edi
    8bf9            mov     edi,ecx
    f7879807000000100000 test dword ptr [edi+798h],1000h
    8bf0            mov     esi,eax
    0f855b000400 jne mshtml!CDoc::SetMouseCapture+0x21 (6ca068f1)
    85db            test    ebx,ebx
    0f855a000400    jne     mshtml!CDoc::SetMouseCapture+0x32 (6ca068f8)
    53              push    ebx
    e88d2affff      call    mshtml!CDoc::ClearMouseCapture (6c9b9331)
    
    mshtml!_NULL_IMPORT_DESCRIPTOR+0x420b:
     0000 add byte ptr [eax],al 
    0000 add byte ptr [eax],al 
    0000 add byte ptr [eax],al 
    0000 add byte ptr [eax],al 
    0000 add byte ptr [eax],al 
    0000 add byte ptr [eax],al 
    0000 add byte ptr [eax],al 
    0000 add byte ptr [eax],al

    After FixIt:

    mshtml!CDoc::SetMouseCapture [j:\win7\inetcore\mshtml\src\site\base\ipwnd.cxx @ 3211]:
    8bff            mov     edi,edi
    55              push    ebp
    8bec            mov     ebp,esp
    81eca0000000    sub     esp,0A0h
    53              push    ebx
    8b5d08          mov     ebx,dword ptr [ebp+8]
    56              push    esi
    57              push    edi
    8bf9            mov     edi,ecx
    f7879807000000100000 test dword ptr [edi+798h],1000h
    8bf0            mov     esi,eax
    0f855b000400    jne     mshtml!CDoc::SetMouseCapture+0x21 (6c6d68f1)
    85db            test    ebx,ebx
    0f856d8d6700 jne mshtml!_NULL_IMPORT_DESCRIPTOR+0x420b (6cd0f60b)
    53              push    ebx
    e88d2affff      call    mshtml!CDoc::ClearMouseCapture (6c689331)
    
    mshtml!_NULL_IMPORT_DESCRIPTOR+0x420b:
    66f743260100 test word ptr [ebx+26h],1 
    0f848d7298ff je mshtml!CDoc::SetMouseCapture+0x227 (6c6968a4) 
    e9dc729cff jmp mshtml!CDoc::SetMouseCapture+0x32 (6c6d68f8)
    

    As you can see, the code in the NULL_IMPORT_DESCRIPTOR is the actual logic in this FixIt that stops the vulnerability. It all depended on checking a flag in one of the C++ objects.

    This was a complicated FixIt to build because of all the variations with all the versions we had to shim, so thanks to everyone who helped in examining this case! Specifically, thanks to Michael Howell and Han Li on the IE team for helping test many of the different combinations IE Versions/Languages/Operating Systems, and Elias Bachaalany for advice on safe shim code locations within the address space.

    - Neil Sikka, MSRC Engineering
    @neilsikka

  • Assessing risk for the September 2013 security updates

    Today we released thirteen security bulletins addressing 47 CVE’s. Four bulletins have a maximum severity rating of Critical while the other ten 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
    MS13-069

    (Internet Explorer)

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

    (Outlook)

    Victim views or previews email having a large number of embedded S/MIME certificates. Critical 2 Unlikely to see reliable exploit code within 30 days. We’ve written a blog post describing the difficulty attackers would have in exploiting this for code execution: http://blogs.technet.com/b/srd/archive/2013/09/10/ms13-068-a-difficult-to-exploit-double-free-in-outlook.aspx
    MS13-067

    (SharePoint)

    Attacker engaged in a session with victim SharePoint server tampers with the viewstate value used to maintain state, potentially resulting in code execution server-side. Critical 1 Likely to see reliable exploits developed within next 30 days. By default, SharePoint requires users (including attackers) to authenticate. This is not a pre-authentication vulnerability unless the SharePoint server is configured to not require authentication.
    MS13-070

    (OLE32)

    Victim opens malicious Visio file. Critical 1 Likely to see reliable exploits developed within next 30 days. Most likely to be exploited via Visio attack vector. But vulnerability is also reachable via shell (Explorer) preview functionality.
    MS13-072

    (Word)

    Victim opens malicious Word document. Important 1 Likely to see reliable exploits developed within next 30 days. Office 2013 not affected.
    MS13-073

    (Excel)

    Victim opens malicious Excel spreadsheet. Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS13-074

    (Access)

    Attacker lures victim to double-clicking a malicious Access database (.accdb) Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS13-076

    (win32k.sys)

    Attacker who is already running code on a machine uses this vulnerability to elevate from low-privileged account to SYSTEM. Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS13-079

    (Active Directory)

    Attacker sends malicious LDAP request to a domain controller, resulting in a denial of service condition. Important n/a Denial of service only.  
    MS13-071

    (Windows Theme)

    Attacker lures victim to double-clicking a malicious .theme file. Important 1 Likely to see reliable exploits developed within next 30 days. Does not affect Windows 7 or later platforms.
    MS13-075

    (IME)

    Attacker who is already running code on a machine uses this vulnerability to elevate from low-privileged account to SYSTEM. Important 1 Likely to see reliable exploits developed within next 30 days.  
    MS13-077

    (Windows Service Control Manager)

    Attacker able to modify the registry on a system uses this vulnerability to elevate from low-privileged account to SYSTEM. Important 2 Less likely to see reliable exploits developed within next 30 days.  
    MS13-078

    (FrontPage)

    Victim opens malicious XML document in FrontPage, leads to information disclosure. Important n/a Information Disclosure only  

    - Jonathan Ness, MSRC Engineering

  • MS13-068: A difficult-to-exploit double free in Outlook

    MS13-068 addresses a memory corruption vulnerability accessible by simply previewing a message in the Outlook Preview Pane. As such, we’ve rated this security vulnerability as Critical and we encourage customers to deploy the security update. However, in this case, we believe this particular vulnerability will be difficult to exploit for code execution. In fact, we’re not certain that the issue is exploitable at all but out of an abundance of caution and because attack technology improves over time, we are issuing the security update today. In this blog post, we’d like to share more information about the vulnerability and the different options an attacker might otherwise have to exploit this class of vulnerability.

    Root cause of the vulnerability

    S/MIME allows nesting of signed messages. When encountering a message with a certain configuration of nested S/MIME certificates, Outlook crashes due to freeing a previously freed class instance pointed to by pPrivBody:

    HRESULT CSMime::SMIMEINFOToOptions( 
       IMimeMessageTree * const pTree, 
       const SMIMEINFO *  psi, 
       HBODY              hBody) 
    {
       CMessageBody *      pPrivBody = NULL;
    
    //...
       for(iLayer = 0, psldLoop = psi->psldLayers; psldLoop != NULL; 
           psldLoop = psldLoop->m_psldInner, iLayer++) {  
    
    //...
               pPrivBody->Release();  // Free here
    //...
        }
    
    // ...
    
       if (pPrivBody != NULL) pPrivBody->Release(); // Double free
       return hr; 
    }
    

    Exploitability for remote code execution

    There are several known conditions that could enable a double free vulnerability to be likely exploitable. The first condition involves a heap allocator adding a memory chunk to free list on the first free and this memory chunk not being used and not coalesced until the second free. A later heap allocator could then use this memory chuck in an allocation request. Regarding this particular vulnerability in Outlook, this condition is not always met because the freed heap block can be reused between the two frees according to the code logic.

    There is also a second condition for a double free to be exploitable for code execution. That involves an attacker being able to write what he wants where he wants (a.k.a, “write-what-where”). However, that is not the case with MS13-068. Here’s a typical crashing instruction when the Outlook vulnerability is triggered:

    eax=00000000 
    inc     dword ptr [eax+14h]  ds:0023:00000014=????????
    

    As we can see it does create a write access situation. However, it appears that “what” and “where” parts are far from attacker-controllable as eax is not under attacker’s direct control and the instruction merely increments the value at eax+0x14.

    Gathering these described above and other data we have, we feel that it is unlikely to be exploited in near term due to difficulty in building a reliable exploit.

    - Jinwook Shin, MSRC Engineering