PDF理解软件补丁
开发和部署补丁是软件开发过程中日益重要的组成部分。
JOSEPH DADZIE，微软
随着软件运行的规模、复杂性和配置数量的大幅增长，软件补丁已成为当今计算环境中日益重要的方面。软件架构师和开发人员竭尽所能构建安全、无缺陷的软件产品。为了确保质量，开发团队利用他们掌握的所有工具和技术。例如，软件架构师将安全威胁模型融入到他们的设计中，QA工程师开发包含复杂代码缺陷分析工具的自动化测试套件。
然而，即使在理想条件下，问题总是会出现。大多数软件将在不断变化的用户环境中使用多年。这可能会对软件提出新的兼容性要求，并引入最初未预料到的新的安全漏洞。无论来源如何，任何软件都可能发现问题，并且必须通过补丁来解决。
本文介绍了软件补丁生命周期，并从软件产品开发人员和需要应用补丁的用户的角度，介绍创建补丁、部署补丁和监控其有效性所涉及的一些挑战。虽然读者可能熟悉此处讨论的许多问题，但我的目的是提供一个关于补丁的概述，这将有助于在解决这些问题时构建思路，而不是提出针对问题本身的具体解决方案。主要关注点是安全补丁，但讨论的问题同样适用于任何软件中与安全无关的缺陷。
识别问题
安全相关的补丁在软件开发领域很常见。在许多情况下，安全研究人员和黑客会发现开发周期中遗漏的漏洞，但软件供应商在产品发布后也会自己发现一些。在最佳情况下，发现问题的人会立即通知供应商，然后在公开宣布漏洞之前通知。然而，有时他们不会这样做。在某些情况下，他们甚至在修复程序可用之前公开发布漏洞利用代码，从而大大增加了受影响组件用户的风险。
无论漏洞的来源如何，软件供应商都有责任研究该问题，如果有效，则生成补丁以解决该问题并尽可能广泛地分发它。
开发补丁
一旦确定了漏洞，补丁开发过程就开始了。该过程的主要目标是发布一个补丁，该补丁解决已识别的问题（和相关问题），并且在相对较短的时间内不引入功能倒退，具体取决于如何发现漏洞以及“示例”漏洞利用代码是否公开可用。
理解问题
开发补丁需要对问题有透彻的理解，而不仅仅是查找者报告的内容。在某些情况下，漏洞可能是一个简单的代码缺陷，可能很容易修复。在其他情况下，它可能是一个更困难的架构问题，或者两个组件之间交互的问题。
然而，即使是简单的代码缺陷也可能不容易修复。例如，缺陷可能在一个组件中，但漏洞利用发生在其他地方。Microsoft 安全公告 MS03-007 中修复的 WebDAV 问题就是其中一个例子。虽然漏洞利用发生在 WebDAV 中，但实际问题发生在操作系统中 6,000 多个其他组件使用的内核函数中。当您有 6,000 个调用者时，简单的代码缺陷不再容易修复。其中一些调用者实际上可能依赖于您现在确定为有缺陷的行为，如果您修复它，可能会出现问题。
为了完全理解问题的范围，需要完成的一些关键问题包括
• 问题是否只影响软件组件的单个版本、多个版本或过时版本？
• 该组件是否是许多其他应用程序依赖的平台组件？
• 软件中的其他组件是否具有可能需要解决的类似漏洞？
• 易受攻击的软件组件是否与其他软件重新分发？
设计/创建修复程序
即使在理解问题之后，在尽可能短的时间内创建健壮的修复程序也并不总是像看起来那么简单。例如，找到具有易受攻击代码专业知识的开发人员并不总是可能的。这可能仅仅是因为组件的原始开发人员不再从事该组件的工作，或者该开发人员已经离开了公司。或者可能是因为该组件已经多年没有被触及；因此，没有活跃的所有者来处理它。几年前，微软发布了一个针对 Gopher 中漏洞的修复程序，但很难正确修复，因为当时 Gopher 协议没有活跃的所有者。
如果漏洞位于公共代码路径中或组件嵌入在其他软件中，则修复程序的设计将变得更加复杂。最近的 JPG 漏洞 (MS04-028) 是公共代码路径和重新分发组件问题的极端案例。不仅操作系统以及微软和第三方产品中的许多不同组件都使用了 JPG 解析器，而且许多产品都附带了自己的 JPG 解析器版本。因此，设计正确的修复程序以涵盖所有情况和版本是一个巨大的挑战。
权衡和决策
创建正确的修复程序可能涉及权衡。必须仔细关注安全性和功能性问题，并理解功能上的损失很可能被客户视为负面影响。
一个常见的争论话题是修复程序的范围和发布时间表。例如，如果公开存在概念验证漏洞利用代码，则可能会决定缩短正常的补丁开发流程，以便更快地发布修复程序。这可能会导致修复程序不如经过正常流程的修复程序稳定。例如，在 2004 年秋季，互联网上公共邮件列表上发布了针对 Internet Explorer 中先前未知漏洞的漏洞利用代码。几天之内，真实的漏洞利用就被用来破坏数千个系统。微软不得不绕过正常的补丁程序来发布修复程序以防止漏洞利用。
另一个决策点是如何创建一个修复程序，最大限度地减少受影响软件中潜在的功能损失。如果受影响的组件是许多其他软件所依赖的平台，则这一点尤其重要。例如，考虑到当今依赖 Internet Explorer 的网站和应用程序的庞大数量，必须谨慎地对 Internet Explorer 进行补丁，因为它既提供浏览体验又提供开发环境。
如果问题影响组件的多个版本，则最好为所有版本提供单个修复程序，但这并非总是可能，因为代码库不同、使用的编译器不同、语言环境不同等。例如，在 1999 年，微软宣布了一个针对 Internet Information Services 3.0 和 4.0 (MS99-022) 中漏洞的补丁，该漏洞仅影响默认语言为双字节语言（如韩语、日语或中文）的系统。在这种情况下，一个补丁修复了所有双字节语言中的问题。在其他情况下，修复程序可能无意中无法在某些本地化版本的操作系统上工作。MS03-045 就是这种情况，其中补丁在运行某些非英语版本的计算机上安装时出现问题，而在其他计算机上则可以工作。
如果漏洞位于公共代码路径或具有 API 的组件中，则需要进行非常广泛的兼容性测试，以确保功能损失尽可能小。如果受影响的组件嵌入在非贵公司开发的软件中，则兼容性测试将变得更加复杂。这些其他组件所有者需要参与到该过程中，以确保他们的客户在发布修复程序时也能受到保护。MS02-039 中讨论的漏洞就是一个很好的例子，该漏洞在 2003 年被 Slammer 病毒利用。
在任何情况下，补丁的兼容性测试永远不如主要甚至次要软件版本的兼容性测试广泛。原因是补丁总是为了修复某些现有的问题而发布的，因此存在尽快发布补丁以保护客户的压力。问题是，如果测试过程缩减得太多，补丁的稳定性将受到影响，从而降低客户对补丁的信心，当然，还会出现其他潜在问题，包括数据丢失。软件越大、越复杂，可用版本越多，测试过程必须越长。
开发人员不应认为补丁开发过程已完成，除非威胁模型、设计规范、测试计划和代码分析工具已更新，以确保在开发新软件时捕获类似类型的漏洞。
创建可部署的软件包
在修复程序开发完成后，必须将其打包成最终用户可以轻松部署和安装的形式，通常通过自动化补丁管理解决方案。补丁管理系统可以由供应商提供，例如微软的 Windows Update、苹果的软件更新服务和 Red Hat Network；或由独立的工具提供，例如微软的 Systems Management Server。
考虑到任何产品在其生命周期中都可能有多个漏洞需要解决，因此必须建立流程，以确保补丁不会撤消/冲突同一组件中的先前补丁，并且必须为给定产品的所有补丁选择标准打包格式。打包格式通常取决于软件使用的安装技术。打包格式的示例包括 Windows 的 Windows Installer 和 Linux 的 RPM (Red Hat Package Management)。
一旦确定了打包格式，完成的软件包必须易于部署到广泛的用户和配置。无论格式如何，补丁都必须采用自包含的软件包，该软件包易于通过名称、目标应用程序或操作系统、处理器架构和语言环境来识别。此外，必须描述和指出补丁与先前发布的补丁的关系。
无论描述多么清楚，除非补丁软件包易于安装，否则它们都无法轻松部署。这意味着软件包必须支持通过目标操作系统的命令行进行静默安装。相同应用程序的所有补丁的静默安装选项必须相同，以减轻将补丁集成到补丁管理解决方案中的管理成本。一旦启动，如果可能，安装过程不应要求重新启动操作系统或受影响的应用程序。为了实现这一点，开发人员需要考虑重要的技术问题，例如服务/守护程序是否可以自动重新启动，以及是否可以在运行时修补内存中的代码。如果无法避免重新启动，则软件包必须提供一个选项，允许补丁管理工具抑制或控制重新启动，以最大限度地减少将多个补丁应用于系统时的重新启动次数。
与软件产品本身一样，安装补丁并不总是顺利进行。因此，补丁安装必须将其活动记录到公共日志中，以便在发生问题时可以跟踪补丁应用程序过程以进行报告和调试。补丁还应支持卸载或回滚。如果补丁出现问题，这一点尤其重要。卸载或回滚过程必须考虑可能相对于发布顺序安装的补丁。
最后，必须保护补丁免受篡改，并通过数字签名、哈希或校验和验证其完整性。数字签名是首选，因为也可以验证补丁的来源。
对于与其他软件重新分发的组件，创建可部署的软件包是一个更复杂的过程。同一系统上是否可以驻留多个版本的组件？这些版本是否使用相同的安装程序技术或不同的安装程序技术发布？如果它们不同，则需要制定策略来为不同的程序创建正确的软件包。
可部署的软件包用于对受影响系统（包括不同的处理器架构和语言环境）上的补丁进行回归和兼容性测试。
分发补丁
一旦验证可部署的软件包可以修复问题并已通过所有回归和兼容性测试，该软件包就可以进行广泛分发了。分发补丁不仅仅是将修复漏洞的软件包提供给客户。可能需要随补丁一起提供有关漏洞、受影响组件（包括文件版本）、依赖应用程序和更改文件的详细信息。需要通知客户补丁的可用性，以便他们可以尽快在其系统上下载和部署补丁。同样重要的是提供有关问题严重性、修复程序的紧迫性以及在客户无法立即部署补丁的情况下可能的缓解措施的信息。恶意用户通常会使用漏洞的详细描述、潜在的攻击向量以及已修补和未修补的二进制文件本身来创建漏洞利用程序。一个有能力的攻击者可能在几分钟内就能做到这一点。因此，必须决定最终用户和企业管理员需要多少信息才能正确部署补丁，而不会向攻击者提供他们可以用来攻击无辜用户的多余信息。
重要的是补丁能够快速有效地分发给最终用户，尤其是在补丁解决关键安全漏洞时。为了实现这一点，补丁分发系统/服务必须包括一种自动方法，以便轻松地将补丁分发到最终用户的计算机。此补丁分发服务必须具有足够的服务容量和带宽可用性，以处理通常尝试下载补丁的大量并发用户。它还必须包含在容量超出或服务本身受到攻击时确保服务的规定。当利用易受攻击系统的蠕虫试图攻击分发服务时，这一点至关重要。2003 年 Blaster 病毒的发布就是一个例子，当时该蠕虫试图对交付补丁的 Windows Update 服务器 (windowsupdate.com) 发起拒绝服务攻击。
补丁开发人员不仅必须考虑其整个分发系统的带宽，还必须考虑下载单个补丁所需的特定带宽。这对于拨号用户尤其重要。补丁可能为几兆字节，而攻击有效负载可能只有几百字节，这使得拨号连接的计算机特别容易受到攻击。
如前所述，拒绝服务攻击的可能性使补丁分发过程变得复杂。需要考虑的另一个挑战是病毒是否可以找出哪些计算机需要补丁，并阻止这些计算机下载补丁，或者在它们下载补丁之前利用它们。补丁分发服务必须在其设计中考虑到这一点。
一个相关的问题是确保用户他们正在与合法的服务对话，并且他们下载的补丁确实是他们声称的那样，而不是某些恶意病毒。证书通常用于此目的，但需要决定服务是信任本地计算机上安装的所有证书，还是仅信任特定证书（包括检查它们是否已被吊销）。
除了已经讨论的带宽和安全问题外，在向最终用户分发补丁时还应考虑其他几个问题，包括
• 如何描述补丁之间的依赖关系
和处理？
• 补丁分发系统如何处理用户卸载补丁的情况？它是否尝试强制推送？它是否发送用户正在卸载它的状态报告？
• 在其环境中部署系统的管理员是否可以获取有关哪些计算机已打补丁以及哪些计算机未打补丁的数据？
监控补丁状态
一旦补丁可供下载，分发补丁的服务或管理工具必须跟踪补丁下载和安装的状态，主要目标是在可能受影响的计算机上实现补丁的高安装率。跟踪还有助于确定补丁是否实际到达所有（或大部分）可能受影响的用户，是否已成功安装，以及是否与其他应用程序引入任何兼容性问题。
如果补丁分发服务被用作主要分发机制，则跟踪/监控补丁状态的任务将变得更加容易。需要记住的一些关键事项是
补丁下载状态。客户是否成功下载补丁？如果不是，您的下载服务器可伸缩性是否存在问题？
补丁安装可靠性。下载的补丁是否在没有错误的情况下安装？您是否了解遇到的错误及其原因？故障是否在定义的故障阈值内？用户是否知道正在发生故障，还是静默故障？
重启。是否为需要重启的补丁执行了重启？如果未发生重启，则需要系统重启的补丁不一定已成功安装。
安装率。在发布后的第一天、第一周、第二周和第一个月内，有多少用户安装了补丁？用户为什么不安装补丁？是否存在需要解决的兼容性问题？
补丁优先级。监控系统是否考虑到某些补丁取代其他补丁的事实？
补丁接收者的角度
到目前为止，我从补丁提供者的角度概述了补丁开发和部署过程。但是，如果我不从接收者的角度谈论补丁管理，我将是失职的。我对这个角度的讨论不仅应该帮助补丁接收者思考应用补丁所涉及的突出问题，而且还应该对补丁提供者有所帮助，作为一种扩展他们自身思维方式以包含其预期用户思维方式的方法。我鼓励您查看 George Brandman 在本期中发表的文章“企业补丁”，以更全面地讨论在大型企业中管理供应商发布的补丁。现在，我将简要概述客户在修补其已安装的软件产品时处理的一些关键问题和疑问。与之前关于补丁开发/部署的讨论一样，我倾向于关注安全相关的补丁，但大多数这些考虑因素同样适用于与安全无关的缺陷。
运行需要补丁的软件的客户在供应商提供补丁后需要考虑不同的问题。首先是客户要知道他们正在使用的软件实际上有补丁可用。他们是否有系统的方式收到通知，还是在新闻中发现的？一旦客户意识到有补丁，他们就需要决定是否部署它。
对于没有 IT 人员的家庭用户或最终用户，前面描述的供应商补丁管理系统应该使他们非常容易安装补丁，而无需成为专家。然而，对于企业客户而言，决定是否部署补丁更为复杂。要回答的第一个问题是：补丁是否与他们的网络相关？如果是这样，则必须识别易受攻击的系统，并且必须确定防火墙和其他网络边界保护技术是否为漏洞利用提供了缓解措施。
识别易受攻击的计算机
识别可能需要修补的易受攻击的计算机和软件实例可能很简单，也可能很困难，具体取决于许多因素
• 正在使用的补丁管理工具（如果正在使用）是否可以自动检测易受攻击的系统，或者 IT 人员是否必须根据补丁随附的信息编写自定义脚本？检测方法是否适用于多种语言环境？
• 移动用户所占比例是否相当大？他们多久登录到网络？检测易受攻击系统的方法必须考虑到并非所有计算机都始终在网络上，因此需要实施策略以在这些易受攻击的计算机进入网络后立即识别它们。
• 是否有一种方法可以确定可能没有或可能没有补丁管理工具或基础设施的远程办公室中计算机的漏洞？远程办公室通常既没有安装补丁管理工具，也没有可以确保计算机已打补丁的管理员。修补这些远程办公室的策略是什么？
• 虚拟机/磁盘映像上是否安装了易受攻击的软件？网络上是否有所对此类映像的清单，以便可以制定计划来更新它们？
• 开发和测试网络呢？在这些网络中，新的操作系统和应用程序会频繁安装和卸载？
企业管理员需要根据对这些问题的解答制定策略和补丁管理流程，以便快速识别和修补其网络上易受攻击的计算机。
部署和安装补丁
一旦公司识别出易受攻击的计算机，就可以部署补丁了。与补丁开发人员一样，公司在决定在其组织内的计算机上部署和安装补丁时必须考虑许多问题。当然，其中一些担忧与发布补丁的软件供应商的担忧重叠。
部署补丁的公司必须首先确定是否存在野外漏洞利用。如果补丁至关重要，漏洞利用可能会导致跳过某些兼容性测试。它还可能导致在计算机上强制安装补丁以保护网络。
公司必须决定是否需要测试所有应用程序或仅测试某些应用程序的兼容性。关键任务应用程序可能需要格外小心，以确保业务在修补后仍能正常运行。企业应确定其计算机上是否运行着易受攻击组件的多个实例。如果其中一些计算机是业务关键型的，则可能无法修补，除非在维护窗口期间。
如果业务关键型应用程序依赖于易受攻击的组件，则如果应用的补丁未获得供应商批准，则应用程序的支持合同可能会失效。对于应用于服务器计算机的补丁，公司应考虑这些计算机是否是集群计算机。
基于这些问题，公司可能会决定在某些关键计算机上采用缓解措施，而不是立即应用补丁。这是一个有风险的提议，但这取决于 IT 人员进行风险评估。它可能会决定在常规维护窗口之外安排停机时间，或者除非安装了特定补丁，否则阻止网络访问易受攻击的计算机。
监控补丁合规性
从企业环境中的客户角度来看，补丁过程的最后阶段是监控合规性状态，以确保网络免受漏洞攻击。必须持续进行此监控，因为新的未打补丁的系统和应用程序会安装在网络上。可能需要隔离易受攻击的计算机并尽快对其进行修补。
补丁的责任
补丁周期是一个复杂的过程，在软件的开发和使用过程中需要仔细考虑不同的方面。需要不断改进这些流程，以快速有效地保护计算机并使其保持最新状态。
软件发布商/补丁开发人员有责任快速解决漏洞、主动通知其客户，并提供足够的信息和工具，以便快速部署补丁。最终用户有责任通过快速有效地部署补丁而不中断其业务来保护其软件资产。
喜欢还是讨厌？请告诉我们
[email protected] 或 www.acmqueue.com/forums
JOSEPH DADZIE 是微软 Windows 软件分发技术组的项目经理。他在微软工作了九年多，专注于软件安装、部署和分发技术。他目前负责软件分发技术。他拥有达特茅斯学院的工程科学学士学位和工程学士学位。
© 2005 1542-7730/05/0300 $5.00
最初发表于 Queue 第 3 卷，第 2 期—
在 数字图书馆 中评论本文
更多相关文章
Emery D. Berger - 软件需要安全带和安全气囊
就像死亡和税收一样，有缺陷的代码是生活中不幸的事实。几乎每个程序在发布时都带有已知错误，并且可能所有程序最终都会出现仅在部署后才发现的错误。造成这种可悲状况的原因有很多。
Alex E. Bell - UML 热：诊断和恢复
传染病研究所最近发表的研究证实，多种多样的 UML 热1菌株继续在世界范围内传播，不分青红皂白地感染软件分析师、工程师和经理。观察到发烧最严重的副作用之一是开发软件产品的成本和持续时间显着增加。这种增加主要归因于受发烧影响的个人在对交付产品几乎没有价值或没有价值的活动上投入时间和精力而导致的生产力下降。例如，开环热患者继续为未知的利益相关者创建 UML（统一建模语言）图。
George Brandman - 企业补丁
软件补丁管理已发展成为一项关键业务问题——从风险和财务管理角度来看都是如此。根据 Aberdeen Group 最近的一项研究，2002 年企业在操作系统的补丁管理上花费了超过 20 亿美元1。Gartner 研究进一步指出，运行良好管理的 PC 的年度成本比未管理的 PC 大约低 2,000 美元2。您可能会认为，凭借临界质量和更复杂的工具，大型组织中每个端点的管理成本会更低，尽管实际上可能并非如此。
© 保留所有权利。