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