Security Research & Defense

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

October, 2012

  • Assessing risk for the October 2012 security updates

    Today we released seven security bulletins addressing 20 CVEs (7 Microsoft and 13 Oracle CVE’s). Only one of the bulletins is rated Critical. The other six 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 Index Likely first 30 days impact Platform mitigations and key notes


    Victim opens a malicious RTF file attachment or previews a rich text email in the Outlook preview pane with Word set as default viewer, resulting in potential code execution in the context of the logged-on user. Critical 1 Likely to see reliable exploits developed within next 30 days.  


    Attacker submits malicious HTML to a server, bypassing SafeHTML’s sanitization code. The malicious HTML is subsequently displayed to a victim, resulting in potential information disclosure. Important 1 Likely to see reliable exploits developed within next 30 days. We have seen limited, targeted attacks attempting to leverage this vulnerability against Microsoft online services. No known attacks against the products being addressed by MS12-066.

    (FAST Search Server for Sharepoint)

    Attacker having permission to upload malicious content to a Sharepoint server does so, which is indexed by FAST Search Server, resulting in potential code execution in context of the restricted token used by the indexing service. Important 1 Likely to see reliable exploits developed within next 30 days. The SharePoint Advanced Filter Pack that leverages Oracle Outside In technology for indexing is not enabled by default. The process that SharePoint uses for indexing when it is enabled runs with a restricted token similar to the Office 2010 Protected View sandbox. For more information, please see this SRD blog post.


    Attacker able to initiate a network connection from one domain-joined machine to another domain-joined machine can send a malformed request that could cause a NULL dereference in LSASS on the remote computer. Unexpected termination of LSASS will initiate a server reboot. Important N/A No potential for code execution. Attacker must be able to make outbound NTLM authentication request from a domain-joined computer. This traffic is typically blocked at external firewall making the issue less likely to be triggered from attackers originating outside enterprise network.

    (Works 9)

    Victim opens a malicious .DOC file with Works 9, resulting in potential code execution in the context of the logged-in user. Important 2 Combination of difficulty to build working exploit + limited set of customers using this older product makes this vulnerability less attractive to attackers. Affects only Works version 9.


    Attacker able to run code on a system at a low privilege level triggers this vulnerability to disclose contents of memory which could lead to privilege escalation from low-privileged to a higher privilege. Important 3 Less likely to see exploit written for this vulnerability to directly execute code. More likely to see it used as an information disclosure vulnerability to reveal memory contents that would otherwise be unavailable to an attacker running code at low privilege level.  

    (SQL Reporting Services)

    Attacker sends victim a link exploiting a Cross-Site Scripting (XSS) vulnerability on a SQL Reporting Services server for which the victim has access rights. When the victim clicks the link, an automatic action is taken on their behalf on the SQL Reporting Services server that they otherwise might not have wanted to execute. Important 1 Likely to see a XSS exploit developed in next 30 days (no exploit here for code execution on the SQL server or SQL Reporting Services server). The IE XSS Filter, if enabled for Intranet sites, would block attempts to exploit this vulnerability.

    In addition to the seven new security bulletins, we have re-released MS12-043 to make available a security update for Microsoft XML Core Services 4.0 on Windows 8. (MSXML4 does not ship with Windows by default but can be included as a redistributable component with installed applications.)

    We are also revising security advisory 2661254 to note that the update is now available for all customers over Automatic Updates.

    Finally, we are releasing a new security advisory, 2749655, describing potential compatibility issues due to incorrect digital certificate timestamps in recently-released security updates. You can read more detail about that situation in the security advisory and the SRD blog post.

    Please let us know if you have any questions about this month’s release. You can email the MSRC Engineering research team at switech [at] microsoft [dot] com or tune in to the monthly webcast tomorrow at 11 a.m. PDT.  Click here to register for the webcast.

    - Jonathan Ness, MSRC Engineering

  • Security Advisory 2749655 and timestamping

    Today we released Security Advisory 2749655 to alert customers to a clerical error made in code-signing a number of recently released security updates. This error will cause the digital signature to expire and become invalid prematurely – not a security flaw, but an issue that will impair users’ overall security profile. In this blog post, we’d like to provide more background on the mistake, explain the effect of this error on product functionality, and detail our response to the situation.

    What happened?

    All Microsoft security updates are code-signed by our Product Release and Security Services (PRSS) team. This central team also manages the code signing and release process for all production Microsoft software. Unfortunately, due to a clerical error, a subset of binaries processed by the PRSS lab between June 12, 2012 and August 14, 2012 were digitally signed in an incorrect manner.

    The signing error involved the timestamp placed on each file as it was being signed. The certificate used for timestamping was missing a critical attribute that will cause the digital signature to become invalid at the point in the future when the package’s signing key has expired. Normally, the signing key is valid for a reasonably short amount of time, while the timestamp allows the binary to be trusted as “valid” for a much longer period of time.

    Without a properly formed timestamp in place to extend the validity period, these binaries and packages will no longer be trusted as valid as soon as the signing key expires. For some of the affected files and packages, that signing key expiration date falls in the next few months.

    Microsoft’s response to the situation

    We will re-sign and redistribute all files and packages affected by this issue. Today, we are re-releasing an initial batch of four security updates -- MS12-053, MS12-054, MS12-055, and MS12-058 -- with new digital signatures, each of which has been timestamped with a proper timestamping certificate. We are continuing our investigation and expect to re-release additional bulletins as needed in months to come.

    In addition to re-signing and re-distributing the affected files, we are taking an unusual approach to address this issue at the platform layer. The Windows team has created a package with a modified WinVerifyTrust function that makes a special case of the two known timestamping certificates that were missing the critical attribute. This will enable WinVerifyTrust to continue trusting these files and packages while redistribution completes. This WinVerifyTrust package is available as a Critical-class update and will be distributed over Microsoft Update and via Automatic Updates. It is also available on the Download Center directly at (link).

    It is important to note that while WinVerifyTrust is the most common place where this check takes place, there are a number of known and potential points where trust may be verified by a third party (such as anti-malware software or software distribution solutions). If the vendor has not made a similar change to their trust model, these files or packages will fail validation. This is why we plan to re-sign and redistribute all files or packages affected by this issue. Again, the older versions of those files and packages are secure and trustworthy just as they are now, but may fail to be recognized as such in later months if they are not updated as soon as possible.

    How WinVerifyTrust validates code signing signatures

    To put this platform-level change into context (and for those who are not yet familiar with the validation process used by Microsoft products), we’d like to explain the three-step process that WinVerifyTrust uses to validate code-signing signatures. This process is merely a subset of the checks WinVerifyTrust performs, but it should make clear why Security Advisory 2749655 serves an important function.

    First, it examines the signing certificate to confirm that it chains to a trusted root. In case of each of these packages, that trusted root is Microsoft. This first step of validation, then, ensures that you can trust that Microsoft signed each of these packages.

    Next, WinVerifyTrust ensures that the signing certificate has not been revoked.

    Finally, WinVerifyTrust checks that either (A) the certificate is in its validity period, or (B) that it has a timestamp that shows it was signed within its validity period. Because all files and packages signed during this period of time were signed with keys that are still within their validity period, they all pass trust verification. However, when these signing keys start to expire early next year, WinVerifyTrust will start examining the timestamp on these files and packages. With the updated WinVerifyTrust package available today to be downloaded, an option (C) has been added to satisfy this third step of validation. After passing the first two steps of validation, the third step can be satisfied by (A) a signing key still in its validity period, (B) a timestamp that shows it was signed within its validity period, or (C) one of these two specific known timestamping certificates that were missing the critical attribute.

    Call to Action

    We encourage all customers to apply the re-released, re-signed security updates as they become available.  As an additional defense-in-depth measure, we recommend that customers also apply the updated WinVerifyTrust package which serves as an effective way for Windows and Microsoft applications to extend the validity period of these packages beyond the premature expiration date.  We should be clear that the re-released, re-signed security updates by themselves are sufficient to address the potential compatibility issue and the WinVerifyTrust package is not strictly necessary - it is offered as a defense-in-depth option to customers who want to ensure that this issue does not affect them between now and the time they apply the updated security updates.

    - Dustin Ingalls, Windows and Jonathan Ness, MSRC Engineering