Security Research & Defense

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

May, 2009

  • MS09-017: An out-of-the-ordinary PowerPoint security update

    Security update MS09-017 addresses the PowerPoint (PPT) zero-day vulnerability that has recently been used in targeted attacks. We issued security advisory 969136 with workarounds on April 2nd after we first saw the exploits in-the-wild abusing this vulnerability.  We also published an SRD blog entry describing how to analyze exploits and an MMPC blog entry with more details about the exploits we had seen. Now the security update is ready for you to install. This update has a few differences compared to previous Office security updates that we’d like to make sure you understand.

    First, the security update for the Windows versions of Office was ready ahead of our planned release schedule. The Mac version of Office is affected but the packages are still in testing so we are “going live” today with Windows packages only. We normally do not update one supported platform before another but given this situation of a package available for an entire product line that protects the vast majority of customers at risk within the predictable release cycle, we made a decision to go early with the Windows packages. We will revise the security bulletin when the Mac packages are available. None of the PPT exploit samples we have analyzed will reliably exploit the Mac version so we didn’t want to hold the Windows security update while we wait for Mac packages. We are still hard at work on the Mac package testing.

    The next interesting difference from our usual Office updates is that MS09-017 dramatically reduces the attack surface. The Office team is making a smart choice to remove support for the very old PowerPoint 4 converter (PP4X322.DLL) with this security update. “PP40” files cannot even be created anymore with Office XP, Office 2003, or Office 2007 and has not been the default format for many years. Office 2007 and Office 2003 SP2 and SP3 have already removed support for this file format so we are backporting that attack surface reduction down-level with this security update. If you really, really, really need to open a PowerPoint 4 file that you trust to not be malicious, we suggest you temporarily re-enable it with this regkey, open the file, save the file in a newer format, and immediately disable the older format again. This is the best way to limit the risk to which you expose your system.

    And one final note about this update is regarding the 14 vulnerabilities addressed by this bulletin. We are addressing a number of PowerPoint converter cases by removing support for the format (PP40). Others were addressed by back-porting the latest Office 2003 SP3 converter code down-level to Office XP and Office 2000. For example, PP7X32.DLL has gone through extensive changes, addressing the externally-reported vulnerabilities listed in the bulletin but also introducing substantial hardening to the parsing engine. We hope that by doing this comprehensive update and by proactively addressing security vulnerabilities, we reduce the risk and help protect our customers from future vulnerabilities.

    Lastly, only one CVE (CVE-2009-0556) is known to be publicly-exploited based on our telemetry but we’re eager to release fixes for all the vulnerabilities reported. This update significantly hardens all versions of PowerPoint and we really encourage you to apply it as soon as possible!

    Jonathan Ness, MSRC Engineering

    *Postings are provided "AS IS" with no warranties, and confers no rights.*

  • More information about the IIS authentication bypass

    Security Advisory 971492 provides official guidance about the new IIS authentication bypass vulnerability.  We’d like to go into more detail in this blog to help you understand:

    • Am I at risk? If so, what could happen?
    • How can I protect myself?

    Which IIS configurations are at risk?

    Only a specific IIS configuration is at risk from this vulnerability. First, we will list configurations that are not at risk, so some of you reading can quickly stop worrying about your web servers:

    • An IIS server not running WebDAV is safe.
      The Windows Server 2003 IIS (version 6) shipped with WebDAV disabled by default.
    • An IIS server not using IIS permissions to restrict content to authenticated users is safe.
    • An IIS server that does not grant filesystem access to the IUSR_[MachineName] account is safe.
    • An IIS server that hosts web applications using only forms-based authentication is probably safe.

    If your web server meets all of the following criteria, you will want to read on:

    • IF an IIS 5, 5.1, or 6.0 webserver is running with WebDAV enabled;
    • AND the IIS server is using IIS permissions to restrict a subfolder of content to authenticated users;
    • AND file system access is granted for the restricted content to the IUSR_[MachineName] account;
    • AND a parent folder of the private subfolder allows anonymous access;
      THEN an anonymous remote user may be able to leverage this vulnerability to access files that normally would only be served to authenticated webserver users.

    This vulnerability is primarily an information disclosure threat.

    Does the information disclosure vulnerability completely bypass the authentication mechanism?

    Not exactly. The malformed URL causes the IIS access check to incorrectly be made using the IIS metabase access key from a parent directory instead.

    A malicious HTTP request sent to a vulnerable IIS server ends up being evaluated by both the web server and the WebDAV extension. When the WebDAV extension attempts to normalize the URL, it modifies the URL in such a way that the access check is made using the permissions from the parent directory but IIS serves the file in the sub-directory. Therefore, the most likely attack would be a malicious anonymous user requesting contents of a webserver subdirectory that uses IIS permission restricting access to only authenticated users. The root of the webserver would typically grant read access to the anonymous user account so this vulnerability would allow the protected subdirectories to be accessed using the permissions of the webserver root (allowing anonymous access).

    Why do you say “primarily an information disclosure threat”? What else could happen?

    We are still investigating different attack ideas possible using this vulnerability but the original report claimed files could be uploaded and modified. However, what we have found is that the IIS installer applies an NTFS access control entry to explicitly deny write access to the anonymous account (IUSR_[MachineName]) in wwwroot and subdirectories that inherit wwwroot’s ACL. So in the default case, this vulnerability will not allow a malicious attacker to upload or modify webpages.

    Mitigations and Workarounds

    At the top of this blog post, we listed the IIS configurations safe from this vulnerability. Each item could be turned into a workaround or mitigation.

    Workarounds

    Workaround #1: Turn off WebDAV

    Turning off WebDAV might be a good option if you are not using it or can live without out until we have a security update available. You can find instructions at http://support.microsoft.com/kb/241520.

    Workaround #2: Change filesystem ACL’s to deny access to IUSR_[MachineName]

    Remember that there are two levels of permissions for files served by IIS. First, the user must be granted access by the NTFS file system and only then are the permissions in the IIS metabase checked. If you deny access to the webserver anonymous account (IUSR_[MachineName]), the access check bypassed by this vulnerability will not be reached. You can find instructions for hardening file system permissions on a webserver at http://support.microsoft.com/kb/271071.

    Workaround #3: Use URLScan to block malicious requests.

    URLScan helps protect affected systems from attempts to exploit this vulnerability. You can find instructions for deployment URLScan at http://technet.microsoft.com/en-us/security/cc242650.aspx.

    Mitigations

    Mitigation #1: WebDAV is disabled by default on IIS 6 (shipped with Windows Server 2003).

    Mitigation #2: If a web server does not use IIS permissions to restrict access to content, this vulnerability is not relevant.

    Mitigation #3: If a website uses forms-based authentication, this vulnerability is likely not relevant.

    This access check bypass vulnerability is most likely to be hit for websites implementing basic, digest, or integrated authentication. Most Internet-based websites use forms-based authentication (username / password form typed into the server-side webpage). A forms authentication schema implemented as an ISAPI filter on PREPROC_HEADERS would not be susceptible to this vulnerability. However, a forms authentication scheme implemented in an ISAPI extension would be susceptible because WebDAV would still get the request.

    Mitigation #4: IIS installer denies write access by default to the anonymous account (preventing webpages from being uploaded or modified using this vulnerability).

    Thanks to Wade Hilmo and Nazim Lala of the IIS team for help investigating this issue.

    If you have any questions, please send them in to secure@microsoft.com. Thanks.

    - Jonathan Ness, MSRC Engineering

    *Postings are provided "AS IS" with no warranties, and confers no rights.*

  • Answers to the IIS WebDAV authentication bypass questions

    We have heard several questions from customers about the WebDAV authentication bypass issue on IIS. We wanted to post common questions and answers here to help anyone else who might have the same question.

    Question: Is Sharepoint vulnerable to the authentication bypass?

    Answer: No, Sharepoint is not vulnerable to this vulnerability. The Sharepoint team does not use the same code as IIS. Their DAV server goes against their backend SQL store, not the file system.

    Question: Is Outlook Web Access (OWA) vulnerable to the authentication bypass?

    Answer: No, OWA is not vulnerable to this vulnerability. Exchange 2007 and earlier supported the WebDAV protocol but they did so with an Exchange implementation of WebDAV which only reads/write to/from the Exchange store. It does not interact with the filesystem directly.

    Question: How can I find IIS servers in my environment running WebDAV?

    Answer: You can use the IIS Manager interface on the server to quickly tell whether the server is running WebDAV. If you want to do so remotely, you can issue an HTTP request to the server directly:

    $ telnet server 80
    
    OPTIONS / HTTP/1.1
    Host: server
    Accept: */*

    (An extra Enter on the blank line after the Accept will complete the request for the webserver.)

    If you get an HTTP response that looks like the one below, the server is running WebDAV.

    HTTP/1.1 200 OK
    Date: Wed, 20 May 2009 00:52:58 GMT
    Server: Microsoft-IIS/6.0
    X-Powered-By: ASP.NET
    MS-Author-Via: DAV
    Content-Length: 0
    Accept-Ranges: none
    DASL: 
    DAV: 1, 2
    Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIN
    D, PROPPATCH, LOCK, UNLOCK, SEARCH
    Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
    Cache-Control: private

    To evaluate the response for existence of WebDAV, use the following logic:

    • Received 2xx response status to OPTIONS request made to root of site.
    • Response contains DAV header with value 1,2.
    • Response contains MS-Author-Via header which contains DAV value.
    • Response DOES NOT contain X-MSDAVEXT header. Existence of this means its Sharepoint’s DAV.

    To test a server that only accepts HTTPS connections, you can use a tool like wfetch.

    What is the difference between the WebDAV server and the WebDAV Redirector / Mini-Redirector

    Answer: The WebDAV server is a server-side component that facilitates WebDAV Publishing within IIS. The WebDAV server is the component discussed in this blog, the previous SRD blog, and the MSRC security advisory.

    Windows also includes client-side components that make interacting with the WebDAV server easier. The client-side components are not affected by this authentication bypass vulnerability. The WebDAV Redirector is a remote file system over the WebDAV protocol that allows Windows client machines to connect to the WebDAV publishing directory through the command line. The WebDAV Redirector enables you to manipulate files on the Web as though the files exist on a mapped network drive. The WebDAV Mini-Redirector is also known as the WebClient service. This service lets DAV-enabled folders appear as Universal Naming Convention (UNC) shares.

    If you have any questions about this vulnerability, please let us know. Thanks!

    - Jonathan Ness, MSRC Engineering

    *Postings are provided "AS IS" with no warranties, and confers no rights.*

  • Safe Unlinking in the Kernel Pool

    The heap in user mode has a number of different measures built in to make exploiting heap overrun vulnerabilities more challenging. Similar checks have been in debug versions of the kernel pool for some time to aid driver debugging. Windows 7 RC is the first version of Windows with some of these integrity checks turned on in release builds.

    Background

    The vast majority of MSRC cases have historically been in user mode Windows components and applications. It should therefore come as no surprise that this is where MSEC has focused its efforts in developing security mitigation techniques to make it harder for attackers to exploit software vulnerabilities reliably.

    Mitigations such as stack protection (/GS), Data Execution Prevention (DEP), Heap Protection, Address Space Layout Randomization (ASLR) and Structured Exception Handler Overwrite Protection (SEHOP) have made reliably exploiting any vulnerabilities that do exist far more challenging.

    Over the last couple of years, the proportion of security bulletins affecting the Windows kernel has been increasing, from under 5% in 2007 to just over 10% in 2008 [Bulletins]. We therefore decided to look again at possible mitigations in the kernel. A number of the bulletins addressed pool overruns (for example MS07-017, MS08-001, MS08-007, MS08-030) so we reconsidered the cases for and against including pool validation checks in free builds. Irrespective of whether a particular vulnerability would have resulted in denial of service or code execution, mitigating the pool overrun ensures the former.

    Pool Overruns

    The pool in the kernel is analogous to the heap in user mode. It is designed to be a high performance dynamic memory manager. There are two types of pool memory.

      • Nonpaged pool is memory that is guaranteed always to reside in physical memory and can therefore be accessed at any time from any IRQL. It is a very scarce resource.
      • Paged pool is memory that can be paged in and out of physical memory. It cannot be accessed from Dispatch level or above since page faults cannot be satisfied at these levels.

    Pool memory is allocated differently depending on the size of the block requested. Allocations of up to 256 bytes use Lookaside lists which are singly linked lists of blocks of the same size. Allocations from 256 bytes up to 4080 bytes use doubly linked lists of blocks. Both of these have a granularity of 8 bytes. Larger allocations return a whole number of pages. Each block is preceded by an 8 byte header which contains information about the size of the block, the size of the previous block and the type of pool memory. If a block is free, its header is followed by a LIST_ENTRY structure which contains pointers to the next and previous free blocks.

    Pool overruns usually occur as secondary effects of arithmetic errors such as integer overflows. This could be in the calculation for the amount of memory to allocate (as in MS08-001) or in the validation code that ensures a buffer is sufficiently large (as in MS08-007).

    image

    Like heap overruns, pool overruns are commonly exploited by using the unlinking operation when an entry is removed from a doubly linked list to perform two arbitrary overwrites.

    BOOLEAN RemoveEntryList(IN PLIST_ENTRY Entry)
    {
       PLIST_ENTRY Blink;
       PLIST_ENTRY Flink;
       Flink = Entry->Flink; // what
       Blink = Entry->Blink; // where
       Blink->Flink = Flink; // *(where) = what
       Flink->Blink = Blink; // *(what+4) = where
       return (BOOLEAN)(Flink == Blink);
    }

    When a block is freed, if either of the adjacent blocks is also free, then the two free blocks are merged into a single larger block. Merging unlinks the existing free block and leads to the arbitrary write. There are a number of conditions that need to be met for this to happen reliably, but essentially the attacker needs to construct a fake header for the next block and supply a LIST_ENTRY with the desired what/where values. This technique is described in several of the references, with [SoBeIt05] and [Kortch08] specifically focussing on the Pool.

    Safe Unlinking

    Safe unlinking is a very simple idea. In any valid doubly-linked list the following should always hold:

    Entry->Flink->Blink == Entry->Blink->Flink == Entry

    Adding these checks to the code gives us the following.

    BOOLEAN RemoveEntryList(IN PLIST_ENTRY Entry)
    {
       PLIST_ENTRY Blink;
       PLIST_ENTRY Flink;
       Flink = Entry->Flink;
       Blink = Entry->Blink;
       if (Flink->Blink != Entry) KeBugCheckEx(...);
       if (Blink->Flink != Entry) KeBugCheckEx(...);
       Blink->Flink = Flink; 
       Flink->Blink = Blink; 
       return (BOOLEAN)(Flink == Blink);
    }

    Checking that these conditions hold before performing the unlinking operation makes it possible to detect the memory corruption at the earliest opportunity. Pool corruption should always be considered a fatal error, hence the Bug Check. This is the same check that has been in the user-mode heap since XPSP2, while more extensive measures were introduced in Windows Vista [Marinescu06].

    Security

    This simple check blocks the most common exploit technique for pool overruns. It doesn’t mean pool overruns are impossible to exploit, but it significantly increases the work for an attacker. As one security researcher put it, “[safe unlinking] makes pool overruns immeasurably harder to exploit”. One of the main goals of mitigations is to remove generic exploit vectors. Work done on exploiting one pool overrun should not buy an attacker anything when it comes to exploiting a different one. Safe unlinking clearly meets this goal.

    Reliability

    Safe unlinking also has benefits from a reliability point of view. Since the vast majority of pool corruptions will already result in a Bug Check, we would not expect the mitigation to increase the overall number of crashes. What it will do is Bug Check as soon as a pool overrun is detected, preventing further memory corruption with more unpredictable consequences.

    Performance

    One of the prime concerns about adding checks to a high performance piece of code like the pool management is whether it will affect speed. In practice this check adds no more than 8 instructions to the binary in each place it occurs; this is not enough to make a noticeable difference.

    A more serious concern would be if the check might require a paging operation, which is very expensive in terms of performance. In this case, the only memory accessed is already touched by the code, so there is no difference in the paging requirements.

    Running live performance tests bears the theory out, and there is no measurable performance difference between builds with and without the checks.

    Compatibility

    Another concern with mitigations is that some applications may rely on particular behavior of the system that the mitigation prevents. In this case, it is safe to say that pool corruption is always bad. There are no exceptions.

    Conclusion

    We have already seen a significant benefit from the inclusion of safe unlinking in the user mode heap, and we believe this value will carry over into kernel mode.

    - Peter Beck, MSEC Security Science

    *Postings are provided "AS IS" with no warranties, and confers no rights.*

    References

    [Bulletins] MS07-017, MS07-066, MS07-067, MS08-001, MS08-004, MS08-007, MS08-025, MS08-030, MS08-036, MS08-061, MS08-063, MS08-066
    [Solar00] Solar Designer. JPEG COM Marker Processing Vulnerability in Netscape Browsers, Bugtraq Jul, 2000
    [Maxx01] MaXX. Vudo malloc tricks, Phrack 57 Aug, 2001
    [Anon01] Anonymous. Once upon a free(), Phrack 57 Aug, 2001
    [SoBeIt05] SoBeIt. How to exploit Windows kernel memory pool, Xcon 2005
    [Marinescu06] Adrian Marinescu. Windows Vista Heap Management Enhancements, Blackhat Vegas 2006
    [Kortch08] Kostya Kortchinsky. Real World Kernel Pool Exploitation, SyScan 08 Hong Kong
    [SRDblog] MS08-001 (part 3) – The case of the IGMP network critical, January 2008

  • New vulnerability in quartz.dll Quicktime parsing

    Recently, we found a remote code execution vulnerability in Microsoft’s DirectShow platform (quartz.dll) when processing the QuickTime format. We have released advisory 971778 providing guidance to help protect customers. We’d like to go into more detail in this blog to help you understand:

    • Which configurations are at risk?
    • Why is this a high risk vulnerability?
    • How can I protect myself?

    Which configurations are at risk?

    The vulnerability is in DirectShow’s code to process QuickTime format. The QuickTime Movie Parser Filter in DirectShow has been removed from Windows Vista and later operating systems (see http://msdn.microsoft.com/en-us/library/dd377491(VS.85).aspx). Windows Vista, Window Server 2008, and later versions of Windows are not affected by this vulnerability.  Older Windows platforms are vulnerable, as shown in the advisory.

    If I have installed Apple’s QuickTime, am I safe?

    Our investigation has found that the installation of Apple’s QuickTime does NOT mitigate this DirectShow’s vulnerability.

    To be clear, whether you’ve installed Apple’s QuickTime or not, the vulnerability is in the Microsoft’s quartz.dll and it’s possible to craft an attack to call that DLL on the system regardless of whether Apple’s QuickTime is present.

    Why is this a high risk vulnerability?

    The vulnerability is in the DirectShow platform (quartz.dll). While the vulnerability is NOT in IE or other browsers, a browse-and-get-owned attack vector does exist here via the media playback plug-ins of browsers. The attacker could construct a malicious webpage which uses the media playback plug-ins to playback a malicious QuickTime file to reach the vulnerability in Quartz.dll. Please note this type of attack could happen for any browsers, not IE specific.

    There is also a file-based attack vector by opening a malicious QuickTime file via Windows Media Player to trigger the vulnerability.

    How can I protect myself?

    There are several workarounds that you may consider here.

    #1: Disable Quick Time Parsing in Quartz.dll by deleting the following registry key:

    HKEY_CLASSES_ROOT\CLSID\{D51BD5A0-7548-11CF-A520-0080C77EF58A}

    For X64 delete the following registry key as well:

    HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{D51BD5A0-7548-11CF-A520-0080C77EF58A}

    This is the best workaround because it’s the most surgical. It only disables QuickTime Parsing in DirectShow.  DirectShow's other functionality is not affected. This workaround covers all known attack vectors. Therefore, if you are not concerned about QuickTime content playback via DirectShow, this is the workaround we recommend you apply.

    #2: Kill-bit WMP ActiveX Control

    If you are using IE, this helps mitigate current attacks we have seen in the wild. You can set the following registry key to apply the killbit:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{6BF52A52-394A-11D3-B153-00C04F79FAA6}]
    "Compatibility Flags"=dword:00000400

    The advantage of this workaround is that it still allows you to use Windows Media Player (or other applications) to playback QuickTime content via DirectShow. The disadvantage is that it only protects against the current attacks we see that use IE. Other attack vectors are not covered. For example, it won’t protect other browsers.

    #3: Unregister/ACL quartz.dll

    This workaround is effective but can have significant impacts in your environment. Please refer to our previous SRD blog: “MS08-033: So what breaks when you ACL quartz.dll?” to get more details on this.

    We don’t recommend this workaround because #1 provides the same level of protection with less impact.  However, it is an option listed in the advisory because it is effective protection and to give customers as full a range of options as possible to better protect their environment.

    Chengyun, MSRC Engineering

    *Postings are provided "AS IS" with no warranties, and confers no rights.*