Security Research & Defense

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

June, 2010

  • Help and Support Center vulnerability full-disclosure posting

    Yesterday evening, one of Google’s security researchers publicly released vulnerability details and a working exploit for an unpatched vulnerability in Windows XP and Windows Server 2003. This afternoon, we’ve released security advisory 2219475 with official guidance. We’d like to use this blog entry to share more details about the issue and ways you can protect yourself.

    The vulnerability

    Firstly, Windows 7, Windows Server 2008, Windows Vista, and Windows 2000 are not impacted by this vulnerability. Those platforms do not include the Help and Support Center application, which contains this vulnerability.

    However, Windows XP and Windows Server 2003 do include the Help and Support Center application (helpctr.exe). On those platforms, clicking on an hcp:// link launches helpctr.exe via a registered protocol handler. Launching the Help and Support Center via an hcp:// link is normally safe and is a supported way to launch help content. This is due in part to an “allow list” of safe pages that Help and Support Center checks before navigating to a passed-in page. The Google security researcher found a help page with a cross-site scripting vulnerability and also a mechanism by which to abuse the allow list functionality to access that page with an exploit querystring. Clicking on a malicious hcp:// link leverages the XSS vulnerability to circumvent helpctr.exe’s safety controls and ultimately run an arbitrary exe installed on the machine.

    It’s also important to note that while Windows Server 2003 does include helpctr.exe and the hcp:// protocol handler, the specific exploit posted by the Google security researcher does not result in code execution on Windows Server 2003. We are still investigating this and have not yet ruled out the possibility of code execution.

    How to Protect Yourself

    The full-disclosure advisory included a hotfix tool built by the Google security researcher. Unfortunately it is ineffective at preventing the vulnerable code from being reached and can be easily bypassed. We recommend not counting on the Google hotfix tool for protection from the issue.

    The best workaround is to unregister the hcp:// protocol handler. Doing so will prevent the chain-of-events that leads to the code execution. Here is a registry script to disable the protocol handler:

    Windows Registry Editor Version 5.00

    Pasting this into a .reg file and opening with regedt32 will disable the hcp:// protocol handler. You can find the interactive steps and the rollback instructions in the security advisory.

    The Help and Support Center does use hcp:// links internally so temporarily disabling the protocol handler may impact Help and Support Center’s ability to, for example, initiate Remote Assistance requests.

    We are actively working on a security update to comprehensively address the issue. We are also working on a Microsoft FixIt to automate disabling the hcp:// protocol handler.

    Thanks to the MSRC Engineering team for the quick investigation of this issue: David Ross, Chengyun Chu, Bruce Dang, Andrew Roths, and Jonathan Ness.

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

  • Assessing the risk of the June Security Bulletins

    Today we released ten security bulletins.  Three have a maximum severity rating of Critical and seven 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.


    Most likely attack vector

    Max Bulletin Severity

    Max Exploit-ability Index Rating

    Likely first 30 days impact

    Platform mitigations and key notes



    Victim browses to a malicious webpage.



    Proof-of-concept has been presented publicly for Information Disclosure issue.

    Likely to also see exploit released for one or more of these memory corruption vulnerabilities.

    IE users on later platforms at reduced risk due to Protected Mode mitigating the information disclosure issue.  IE8 users on Windows Vista and Windows 7 at reduced risk due to presence of DEP and ASLR.

    Please see this SRD blog post for more information



    Victim browses to a malicious webpage or opens a malicious AVI movie with Media Player.



    Likely to see an exploit released able to exploit the vulnerability in MJPEG parsing.




    Victim browses to a malicious webpage.



    May see an exploit released able to exploit one or both of the Microsoft ActiveX controls.

    CVE-2010-0252:  Victim must have Office XP’s Data Analyzer (MSDA) package installed to be vulnerable.

    CVE-2010-0811: User interaction required


    (kernel drivers)


    Attacker already running code with low privileges on a vulnerable machine runs a malicious EXE to elevate to a higher privilege level.



    Likely to see an exploit released able to elevate from a low privileged user on the box to a higher privilege.

    Please see this SRD blog post for more information about exploitability



    Victim opens a malicious XLS file that exploits a vulnerability to run arbitrary code.



    Exploit likely to be developed for one of more of these XLS parsing vulnerabilities in the next 30 days.



    (Office ActiveX)

    Victim opens a malicious Office document that instantiates an ActiveX control to result in code execution.



    Likely to see malicious Office documents that exploit this within the next 30 days.




    Victim clicks an attacker-sent link to a Sharepoint server on which they have administrative rights.  Attacker-supplied link causes them to take an automatic action on the Sharepoint Server.



    Proof-of-concept already public for this issue.  However, we have not heard of real-world attacks from either customers or partners.




    Attacker connects remotely over HTTP to IIS server that has installed the (optional) Channel Binding Update and has enabled (off-by-default) Windows Authentication.



    Less likely to see exploits developed resulting in successful code execution in next 30 days.




    Local user running at low privileges on a vulnerable machine runs a malicious EXE to elevate to a higher privilege level.



    Less likely to see exploits developed resulting in successful code execution in next 30 days




    Custom .NET applications that rely on XML signature protection as tamper protection could be tampered with in an undetected manner. 



    Unlikely to see exploit developed in the next 30 days.

    No Microsoft .NET applications are vulnerable to this issue.  Usage of the specific API thought to be low in real-world.

    Please see this SRD blog post for more information


    Special thanks to all of MSRC Engineering for their work on these cases.

    - Jonathan Ness, MSRC Engineering

  • MS10-032: Vulnerabilities in Windows Kernel-Mode Drivers Could Allow Elevation of Privilege

    Today we released a security update rated Important for CVE-2010-1255 in MS10-032.  This vulnerability affects the win32k.sys driver.  This blog post provides more information about this vulnerability that can help with prioritizing the deployment of updates this month.


    What’s the risk?


    A local attacker could write a custom user-mode attack application that passes a bad buffer to win32k.sys’s GetGlyphOutline while retrieving font information. This could be an attempt to cause memory corruption with the end goal of running code in ring 0 -- a classic local Elevation-of-Privilege vulnerability. 


    If a regular, known-good application failed to properly request the length of the buffer when calling this API, that application might expose a different code execution attack vector to this vulnerability. Fortunately, default installations of Windows are not at risk because the API is properly used in Microsoft applications. If a third-party application inadvertently used this function incorrectly, this security update will protect any attack vector exposed by that application as well. In that light, the deployment priority of this update may need to be adjusted accordingly.


    How difficult is this to exploit?


    Due to a validation statement in the write loop, the attacker cannot write data of arbitrary length beyond the allocated buffer; the overwrite length is approximately 0x10 bytes.  Getting all of the data in the right place at the right time to gain code execution can be quite unreliable and as a result we gave it an Exploitability Index rating of 2.  We do not expect to see reliable exploit code within the next 30 days.


    We would like to thank Colin McCambridge for his work on this case. 


    - Bruce Dang, Brian Cavenah, and Jonathan Ness from MSRC Engineering

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

  • MS10-035: Cross-Domain Information Disclosure Vulnerability

    Today we released MS10-035, a security update with an Important severity update, addressing CVE-2010-0255. We’d like to talk briefly about that specific vulnerability and how we’ve addressed it.


    Background information


    This issue primarily impacts Internet Explorer running on Windows XP.  Attacks against Internet Explorer running on Windows Vista and newer platforms are mitigated by Internet Explorer Protected Mode.  This issue involves an attacker navigating directly to the user’s cache index file, index.dat, via a UNC path.  Script planted in index.dat could in some cases execute in a security context enabling read access to other content on the local filesystem.  Internet Explorer Protected Mode is a powerful mitigation because it disables the ability to access resources on the local filesystem via UNC paths, by default.


    How would someone take advantage of this vulnerability?


    An attack would involve malicious web content navigating a victim’s browser to a UNC path referencing index.dat on the local filesystem.  Script planted within index.dat would then be able to read data from other local files on the machine.  The attacker could then access files in predictable paths assuming the files were not locked for read or otherwise inaccessible.  (e.g., restricted for read by the current user due to ACLs.)




    All mitigations discussed in the following blog post would apply to CVE-2010-0255 as well:
    MS09-019 (CVE-2009-1140): Benefits of IE Protected Mode, Additional Network Protocol Lockdown workaround


    Specifically, besides Internet Explorer Protected Mode, Network Protocol Lockdown can be used to prevent exploitation of this issue. 


    The code change being made to address CVE-2010-0255 is also present on Windows Vista and newer platforms simply because users or administrators may have manually disabled Internet Explorer Protected Mode.  Future attack scenarios may result in further code changes, though we anticipate that Internet Explorer Protected Mode will continue to provide protection against this overall threat class.


    Thanks to Chengyun Chu for his contribution to this blog post.

    -          David Ross, MSRC Engineering


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

  • MS10-041: XML Signature HMAC Truncation Bypass Vulnerability

    Today we released MS10-041 addressing an issue in the implementation of the XML signature functionality in the .NET Framework with an Important severity rating.  We’d like to shed more light on that case here.


    Am I at risk?


    No Microsoft products are subject to this vulnerability.  However, .NET applications that use the System.Security.Cryptography.Xml.SignedXml.CheckSignature(KeyedHashAlgorithm macAlg) method are susceptible.  Note that only the CheckSignature() method that takes a KeyedHashAlgorithm parameter is affected – the other CheckSignature() methods are not.


    Anyone running applications that call this method should install this update as soon as possible. The update protects against the vulnerability without the need to recompile these applications.


    If you allow updates to install automatically, there’s nothing else you have to do.  Once the update has been installed, your applications will be safe from this vulnerability.  In addition, after extensive evaluation we’ve assigned this vulnerability an overall Exploitability Index rating of 3, meaning that we believe that functioning exploit code is unlikely in the near future.


    What could an attacker do?


    As the bulletin explains, this vulnerability could make it possible for an attacker to modify XML signature protected data without being detected.  The impact of the tampering depends on how the affected data is intended to be used by the specific application, but is unlikely to result in arbitrary code execution.


    Background information


    One of the features of an XML signature is the ability to embed a value, called the HMACOutputLength, in the signature that tells the receiver how many bits of the signature to examine.  However, the specification did not require that implementations of the specification enforce a minimum value for this field.


    In the .NET implementation, as well as other implementations by other vendors, no minimum HMACOutputLength value was enforced, so a man-in-the-middle attacker could set this value to 0 and then tamper with the contents of the XML without detection.


    The updated specification now says that implementations must validate that HMACOutputLength is >= MAX(80, HalfOfTheBitsTheSignatureMethodGenerates).


    XML signatures are defined by the W3C in this document:


    How to determine if you have any affected applications on your computer


    The .NET Framework SDK comes with a disassembly tool which can extract the IL code from a .NET binary.  The following PowerShell script calls this tool for every .EXE and .DLL file under the folder you execute the script in, and examines the output of the tool to tell you if any of the binaries call the vulnerable function.  To run this PowerShell script, you’ll need to install PowerShell if you’re not using Windows 7 (PowerShell comes with Windows 7), and you’ll need to install the .NET Framework SDK or Visual Studio, and finally update the first line of the script to point to the location that ildasm.exe was installed on your computer.


    $PathToILDASM = "C:\Program Files\Microsoft.NET\SDK\2.0\Bin"

    $FilesToScan = get-childitem -Filter *.exe -Recurse
    $FilesToScan += get-childitem -Filter *.dll -Recurse

    "Found " + $FilesToScan.Count + " EXE and DLL file(s) to scan"
    "Binaries that contain calls to System.Security.Cryptography.Xml.SignedXml.CheckSignature(KeyedHashAlgorithm macAlg):"

    foreach($File in $FilesToScan)
        $FileName = $File.FullName
        if (([string]$FileName).Length -gt 0)
            $Process = New-Object -typeName System.Diagnostics.Process
            $Process.StartInfo.WorkingDirectory = (get-location).Path
            $Process.StartInfo.UseShellExecute = $false
            $Process.StartInfo.RedirectStandardOutput = $true
            $Process.StartInfo.RedirectStandardError = $true
            $Process.StartInfo.FileName = [System.IO.Path]::Combine($PathToILDASM, "ildasm.exe")
            $Process.StartInfo.Arguments = "/OUT=temp.txt `"$FileName`" /NOBAR"
            $Process.Start() | out-null
            if (Test-Path temp.txt)
                $Disassembly = Get-Content temp.txt
                del temp.txt
                if (([string]$Disassembly).Contains("callvirt   instance bool [System.Security]System.Security.Cryptography.Xml.SignedXml::CheckSignature(class [mscorlib]System.Security.Cryptography.KeyedHashAlgorithm)"))


    Thanks to Shawn Farkas, Damian Hasse, Joe Hemmerlein, Alex Lucas, and Andrew Roths for their help with this blog post!

    -Kevin Brown, MSRC Engineering