微软安全公告中的额外修复

我们时常收到关于安全公告中未记录修复的疑问，有人称之为“静默修复”。本文旨在解答这些问题，并阐明微软在修复和记录所有漏洞及处理内部发现变体时的流程。需牢记以下几点：

作为微软全面安全更新流程的一部分，微软会处理已报告问题的变体。变体是内部发现的与报告漏洞相似的问题，不会在安全公告中记录。
公告的整体严重性将反映任何已修复漏洞的最高严重性，无论它是外部报告的漏洞还是内部发现的变体。可利用性指数评级也是如此。
微软在公告和博客中提供的指导考虑了安全更新中的所有修复。例如，一个缓解措施将减轻报告漏洞及潜在变体的风险。

安全更新中的额外代码修复

许多安全社区都知道，微软安全更新有时包含额外的代码修复，以解决超出最初报告漏洞的问题。这一确保全面更新的流程首次在2006年6月的微软TechNet杂志文章中公开记录。

我们理解研究人员会在更新发布时进行逆向工程，并寻找与报告漏洞类似的安全漏洞；这些类似漏洞我们称为变体。

MSRC工程团队的审查流程

MSRC工程团队审查每个外部报告漏洞的受影响组件。审查的一部分是“寻找变体”（HfV）阶段，这有助于减轻更新发布后发现变体的威胁。HfV流程由MSRC工程团队和产品团队共同进行，涉及审查源代码和错误数据库，以及对组件进行模糊测试和通过我们的工具套件进行严格测试；其中许多工具是新的或自组件最初编写以来已更新。

关于CVE编号的常见问题

一个常见问题是：“为什么内部发现的变体没有CVE编号？”

CVE（常见漏洞与暴露）索引是“公开已知信息安全漏洞和暴露的字典”。在发布时，任何内部处理的变体都不被视为公开，因为它们尚未由外部研究人员报告给我们，而是由开发人员或安全研究人员自己在我们的安全开发流程中识别。安全更新是我们向客户提供此额外修复的第一个发布载体。

在许多情况下，分配CVE是不切实际的。例如，在某些情况下，安全更新只是从经过SDL流程的新产品版本中回移植代码，或者安全更新将所有不安全的字符串复制API调用转换为安全版本。在这种情况下，很难知道这种批量代码更改解决了多少漏洞。

变体严重性与可利用性指数

另一个问题是：“变体的严重性是否计入微软的严重性评级和指导？”

是的。需要注意的是，安全更新中处理的任何变体的严重性都将计入安全公告的整体严重性和指导中。可利用性指数也是如此；如果发现一个变体比最初报告的漏洞更容易利用，可利用性指数评级也会上调。公告的总体严重性、指导和可利用性指数评级始终考虑变体。

在审查非微软对微软更新的安全评估时，值得记住的是，微软已经考虑了变体的可利用性和严重性，而那些非微软安全评估通常没有考虑，因此您可能会看到一些差异。

鉴于内部发现的漏洞通常是原始漏洞的变体，严重性增加的情况相对罕见，更可能的情况是可利用性指数上升。

实际案例：CVE-2010-3334

例如，去年11月我们修复了CVE-2010-3334，这是一个由Secunia报告的Office组件漏洞。像往常一样，HfV流程完成，并通过模糊测试发现了一个变体。这个特定变体比最初外部报告的漏洞稍微容易利用，因此可利用性指数评级更新为1。严重性保持不变，因为风险未变。覆盖原始漏洞的缓解措施和变通方案也适用于该变体。10月12日，CERT/CC的Will Dorman向我们报告了相同的变体，此时该变体已被修复，该修复已经过测试并影响了公告。这突显了将内部修复添加到更新中的重要性。