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