Security Research & Defense

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

February, 2011

  • Notes on exploitability of the recent Windows BROWSER protocol issue

    Earlier this week a PoC exploit for a vulnerability in the BROWSER protocol was released on Full Disclosure. There has been some discussion regarding whether this issue can result in Remote Code Execution (RCE) or is only a Denial of Service (DoS). This blog post provides details on the exploitability based on our internal analysis.

    Which systems are vulnerable

    All versions of Windows are vulnerable, although the issue is more likely to affect server systems running as the Primary Domain Controller (PDC).  In environments following best practices, the BROWSER protocol should be blocked at the edge firewalls thus limiting attacks to the local network.

    The BROWSER protocol operates on top of SMB and is used to discover machines and resources on the network. It is implemented as a kernel driver (mrxsmb.sys or bowser.sys, depending on the version of Windows).  This vulnerability affects Windows machines that have been configured to (A) use the BROWSER network protocol and (B) that then become Master Browser on the local network. The BROWSER protocol uses an election process to determine which system will act as the “master” in terms of data collection and response handling.

    In normal enterprise networks the Primary Domain Controller (PDC) will become Master Browser, but depending on the network configuration, other computers on the network can become Master Browser, and therefore be vulnerable. A single system will be Master Browser at any point in time. (See the [MS-BRWS] protocol specification for more details).

    Root cause of the vulnerability

    A malformed BROWSER message would cause the Master Browser to hit the vulnerable code below and trigger the vulnerability.

    The vulnerability is due to an integer underflow where a 32-bit length value becomes -1. This is then used in a memcpy call as follows:

    if ( Length > 0 ) {  
        RtlCopyMemory(StringOffset, InsertionString, Length*sizeof(WCHAR));  
    

    The copy length will therefore be -2 (0xFFFFFFFE) on 32-bit systems, and 0x1FFFFFFFE on 64-bit systems. This leads to a kernel pool buffer overrun in the context of a thread running at the PASSIVE IRQ level on Windows XP and Windows Server 2003. On Vista and later platforms, the thread will be running at the DISPATCH IRQ level. Threads running at PASSIVE IRQ level can be pre-empted by the operating system, making exploitation slightly more likely.

    Effects of the buffer overrun

    The copy operation will cause a bugcheck when invalid memory is referenced either from the source or destination address. This bugcheck is almost guaranteed to happen, since roughly 4GB of contiguous memory will be referenced during the copy on 32-bit systems. (On 64-bit systems, roughly 8GB of contiguous memory will be referenced)

    It is impossible to have 4GB of contiguous virtual address space mapped at both the source and destination on 32-bit systems. Having 8GB of contiguous virtual address space mapped may be possible on 64-bit systems with sufficient physical memory.

    RCE may also be possible if the corrupted memory is used before the RtlCopyMemory triggers a bugcheck, and in a way that can be used to change code execution. For instance, a thread running in another processor may reference the corrupted memory in parallel (while the RtlCopyMemory operation is in progress). On platforms where the copy operation is done at the PASSIVE IRQ level, the thread could be pre-empted by a higher-priority thread or hardware interrupt. Should this happen, the higer-priority thread may reference corrupted memory in a way that can lead to RCE.

    We feel that triggering these timing conditions reliably will be very difficult.

    Exploitability for RCE

    Based on the conditions outlined above, while RCE is theoretically possible, we feel it is not likely in practice. DoS is much more likely.

    Looking at the Exploitability Index (XI) rating scale, we would assign this an XI rating of ‘3’ – Functioning exploit code unlikely on Windows Vista and higher. On Windows XP and Wndows Server 2003, the XI rating would be ‘2’ – Inconsistent exploit code likely.

    Thanks to Brian Cavenah and Matt Miller for their input.  The Microsoft Malware Protection Center (MMPC) blog also has some notes on this issue that you can find here:  http://blogs.technet.com/b/mmpc/archive/2011/02/16/my-sweet-valentine-the-cifs-browser-protocol-heap-corruption-vulnerability.aspx

    - Mark Wodrich, MSRC Engineering

    Updated 2/18/11: Updated the IRQ level information and XI rating based on additional internal research.

  • Additional Fixes in Microsoft Security Bulletins

    From time to time we receive questions regarding fixes not documented in security bulletins. Some call these “silent fixes.” We hope this blog post answers those questions and helps clarify Microsoft’s process in fixing and documenting all vulnerabilities and addressing internally discovered variants. 

     

    It’s important to remember the following:

    • As part of Microsoft’s comprehensive security update process, Microsoft will address variants of reported issues. Variants are internally found issues similar to the reported vulnerability, and are not documented in security bulletins.
    • The overall severity of the bulletin will reflect the highest severity of any vulnerability fixed, whether it was an externally reported vulnerability or internally found variant.  The same is also true for the Exploitability Index rating.
    • The guidance Microsoft provides on bulletins and blogs takes into account all fixes done in a security update. For example, a workaround will mitigate the reported vulnerability as well as potential variants.

     

    Much of the security community is aware that Microsoft security updates sometimes contain additional code fixes to address issues beyond the originally reported vulnerability.  This process that ensures a comprehensive update was first publicly documented in a Microsoft TechNet magazine article from June 2006.  

     

    We understand that researchers will reverse engineer our updates when released, and that they will look for similar security vulnerabilities to the one reported; these similar vulnerabilities we call variants.

     

    The MSRC Engineering team reviews the affected component of each externally reported vulnerability.  One part of the review is the “Hacking for Variations” (HfV) stage, which helps mitigate the threat of variants being discovered after the update is released. The HfV process is jointly undertaken by MSRC-Engineering and the product team.  It involves reviewing the source code and the bug database as well as fuzzing the component and hurling it through our gauntlet of tools; many of which are new or have been updated since the component was first written.

     

    A common question we receive is, “Why do internally found variants not get a CVE number?”

     

    The CVE (Common Vulnerabilities and Exposures) index  “is a dictionary of publicly known information security vulnerabilities and exposures”. At the time of release, none of the internally addressed variants are considered public, as they have not been reported to us by an external researcher, but were identified by the developers or security researchers themselves as part of our security development process. The security update is the first release vehicle we have to get this additional fix to customers. 

     

    In many cases allocating a CVE would not be practical, for example, in some cases the security update is simply a back-port of code from a newer version of the product that has gone through the SDL processes or perhaps the security update converted all unsafe string copy API calls to safe versions.  It’s tough to know in cases like this how many vulnerabilities were addressed by this kind of bulk code change. 

     

    Another question we get is, “Is the severity of a variant factored in to Microsoft’s severity rating and guidance?”

     

    Yes. It’s important to note that the severity of any variant addressed by the security update will be factored into the security bulletins overall severity and guidance.  The same thing happens with the Exploitability Index; if a variant is found that is easier to exploit than the originally reported vulnerabilities the Exploitability Index rating will be uprated too. Aggregate severity, guidance and Exploitability Index ratings for a bulletin always take into account the variants.

     

    When reviewing non-Microsoft security assessments of the Microsoft updates, it is worth remembering that where Microsoft has factored in the variant exploitability and severity, those non-Microsoft security assessments generally would not have, hence you may see some discrepancies.

     

    Given that internally found vulnerabilities are normally variations of the original vulnerability, it is relatively rare that the severity will increase, the more likely scenario is that the Exploitability Index will rise.

     

    An example: Last November we fixed CVE-2010-3334 which is a Secunia reported vulnerability with an Office component, as normal the HfV process was completed and through fuzzing, a variant was discovered. This particular variant was slightly easier to exploit than the original externally reported vulnerability, so the Exploitability Index rating was updated to a 1.  The severity remained the same as the risk remained unchanged. The mitigations & workarounds that covered the original vulnerability were also applicable to the variant. On 12th October that same variant was reported to us by Will Dorman from CERT/CC, at this point the variant was already fixed, that fix had already gone through testing and had already influenced the bulletin. This highlights the importance of adding internal fixes to the updates.

     

    For more information about Microsoft’s comprehensive security response process please visit the Microsoft Security Response Center (MSRC) website. Below you will find one part of a four-part series hosted by Tim Rains, Group Product Manager, who is joined by Damian Hasse from the MSRC Engineering team and James Rodrigues from the Windows Serviceability Team to discuss security update quality testing.

     

     

    Thanks to Damian Hasse, Andrew Roths, Jonathan Ness, Richard van Eeden, Maarten Van Horenbeeck and Katie Moussouris.

     

    Gavin Thomas, MSRC-Engineering

     

     

  • Assessing the risk of the February security updates

    Today we released twelve security bulletins. Three have a maximum severity rating of Critical and nine have a maximum severity rating of Important. This release addresses three publicly disclosed vulnerabilities. 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
    MS11-003
    (IE)
    Victim browses to a malicious webpage. Critical 1 Public exploits exist for CVE-2010-3971, as first described in advisory 2488013. Please see MMPC blog post for attack telemetry.  
    MS11-006
    (shimgvw.dll)
    Victim browses to a malicious SMB or WebDAV share that contains a file with a malicious thumbnail image. Critical 1 Public exploits exist for CVE-2010-3970, as first described in advisory 2490606. We have not been alerted to any real-world active attacks. The thumbnail preview attack vector exists only if explorer.exe is in thumbnail or preview mode. By default, explorer.exe uses details mode which cannot be used as an attack vector.
    MS11-007
    (OpenType Font driver)
    Victim using explorer.exe browses to a folder containing a malicious OTF file. Critical 2 Any exploits released in next 30 days likely to be inconsistent and not reliable for code execution. Windows XP and Windows Server 2003 not vulnerable to the shell preview attack vector.
    MS11-004
    (IIS FTPSVC)
    Attackers send malicious exploit against IIS 7 servers that have enabled the FTP service. Important 2 Vulnerability details for CVE-2010-3972 are public. However, it will be difficult to build a reliable exploit for code execution. We have heard rumors of an exploit technique that will be discussed publicly in April by Chris Valasek and Ryan Smith. The FTP service included with Windows Server 2003 and Windows Server 2008 are not vulnerable by default. This blog post explains in more detail how versions of Windows other than Windows 7 and Windows Server 2008 R2 could be impacted.
    MS11-011
    (Kernel)
    Attacker running code on a machine already elevates from low-privileged account to SYSTEM. Important 1 Proof-of-concept code is publicly available.  
    MS11-012
    (win32k.sys)
    Attacker running code on a machine already elevates from low-privileged account to SYSTEM. Important 1 Likely to see an exploit released granting a local attacker SYSTEM level access.  
    MS11-014
    (LSASS)
    Attacker running code on a machine already elevates from low-privileged account to SYSTEM. Important 1 Likely to see an exploit released granting a local attacker SYSTEM level access.  
    MS11-008
    (Visio)
    Victim opens a malicious .VSD file Important 1 Likely to see an exploit released.  
    MS11-010
    (CSRSS)
    Attacker able to logon interactively to a machine runs code and then logs off. Later, when an administrator logs onto the machine, attacker code runs in the administrator’s security context. Important 1 Likely to see an exploit released granting a local attacker access to the security context of the next user who logs into the system.  
    MS11-013
    (Kerberos)

    Two vulnerabilities:

    1 - Attacker already running code locally in the context of a service account (IIS, SQL, etc) elevates privileges on the network. 

    2 - Man-in-the-middle attacker able to sniff and modify traffic on the wire causes encryption downgrade to DES, cracks the encryption, and impersonates the user who sent the traffic.

    Important 1 Likely to see an exploit released allowing an attacker to increase their foothold on a compromised network.

    1 - Services running in the context of a low-privileged account cannot be used as initial vector of an exploit where this vulnerability is used. Domain controllers running Windows Server 2008 or later are not affected.

    2 - Attacker must be able to sniff and modify traffic on the wire.

    MS11-005
    (Active Directory)
    An attacker running code as an administrator of a domain-joined computer could disrupt critical functions of the domain (such as the Kerberos service) by updating properties of the attacker-controlled system in its Active Directory record. Important 3 No exploit possible for code execution. This vulnerability has potential for denial-of-service only. Attacker must first compromise a domain account having administrative access to a workstation in the domain.
    MS11-009
    (JScript / VBscript)
    Victim browses to a malicious webpage allowing attacker to read a few bytes of memory within the victim's Internet Explorer process. Important 3 No exploit possible for code execution. This vulnerability has potential for information disclosure only.  

    In addition to the twelve security updates, we are also releasing an advisory related to the Autorun functionality. This advisory describes a package live today on Windows Update that disables the Autorun functionality for removable, “non-shiny” media. You can read more about it in this blog post.

    Acknowledgement

    Thanks to Andrew Roths, Mark Wodrich, and the rest of the MSRC Engineering team for help with this post and the whole team for their work on this month's security updates.

    Jonathan Ness, MSRC Engineering

  • Regarding MS11-004, Addressing an IIS FTP Services Vulnerability

    Today we released MS11-004 to address a vulnerability in the Microsoft FTP service an optional component of Internet Information Services (IIS). In this blog, we would like to cover some additional technical details of this vulnerability.

    First, we want to clarify that the vulnerability lies in the FTP service component of IIS. The FTP service is an optional component of IIS and is not installed by default.

    One part that may be confusing is the difference between the FTP service version and the IIS version. For example, the version of FTP service shipped with IIS 7 on Windows Vista and Windows Server 2008 is FTP 6.0, not FTP 7.0. However, you could also install FTP 7.0/7.5 as an optional component on IIS 7 from the Microsoft Download Center. If you are unsure what version of FTP service you are running and if your system is vulnerable; use this procedure to determine if the update is needed for your system.

    • If FTP service is not enabled, the system is not vulnerable.
    • If FTP service is enabled,
      • IIS 6 on Windows Server 2003: Not vulnerable
      • IIS 7 on Windows Vista and Windows Server 2008: By default, IIS 7 uses FTP 6.0, which is not vulnerable. However, if you install FTP 7.0/7.5 for IIS 7 package from Microsoft Download Center, then it is vulnerable.
      • IIS 7.5 on Windows 7 and Windows Server 2008 R2: FTP 7.5 shipped with IIS 7.5 is vulnerable.

    Please note there is also a way to automate this process. FTP 6.0 is running with a different service name than FTP 7.0/7.5. Therefore, the idea is to check whether the “ftpsvc” service, the service name of FTP 7.0/7.5, is running or not. In our previous SRD blog Assessing an IIS FTP 7.5 Unauthenticated Denial of Service Vulnerability , we have already talked about the approach. Here we list it again:

    A user can determine the status of the IIS FTP service by querying it through the command prompt (running as administrator):

    • Press the “Windows”+“R” key
    • Type “cmd.exe” (no quotes)
    • In the command prompt type “sc query ftpsvc” (no quotes)

    If the service is not installed then the following will be displayed:

    > sc query ftpsvc
    [SC] EnumQueryServicesStatus:OpenService FAILED 1060:
    
    The specified service does not exist as an installed service.
    

    If the service is installed and running then the following will be displayed:

    > sc query ftpsvc
    SERVICE_NAME: ftpsvc
            TYPE               : 20  WIN32_SHARE_PROCESS
            STATE              : 4  RUNNING
                                    (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN)
            WIN32_EXIT_CODE    : 0  (0x0)
            SERVICE_EXIT_CODE  : 0  (0x0)
            CHECKPOINT         : 0x0
            WAIT_HINT          : 0x0
    

    An alternative approach is to scan the file system to detect whether a machine is vulnerable. . If ‘ftpsvc.dll’ does not exist in the %system32%\inetsrv directory, then your system is not affected. If you find a file named ‘ftpsvc2.dll’ this indicates that you have FTP 6.0 installed on the system and are also not affected by this vulnerability. The detection logic on Windows Update, Microsoft Update, and WSUS will handle the above scenarios, so that the update is only offered to IIS 7 systems that have FTP 7.0 or FTP 7.5 installed.

    Finally, we would like to clarify the exploitability of this issue. We blogged about this issue in December 2010 here, and outlined why we thought remote code execution was unlikely. We said “these characteristics make it difficult to successfully execute a heap spray or partial function pointer override attack. Because of the nature of the overrun, the probable result will only be a denial of service and not code execution.”

    Since then additional research has shown that it may be possible for this vulnerability to be exploited if DEP and ASLR protections are bypassed. No exploit has been seen in the wild, and no exploit code has been made publicly available. To sum up the current situation, while it may be possible to achieve code execution, the probable impact for most customers remains denial of service.

    Acknowledgement

    Thanks to Nazim Lala in the IIS team, the Japan CSS Security Response Team, and Brian Cavenah in the MSRC Engineering team for their work on this.

    Chengyun Chu and Mark Wodrich, MSRC Engineering