OpenSSL 是一个广泛使用的开源软件库，用于通过计算机网络实现安全通信。使用有多广泛？好吧，如果您曾经访问过 HTTPS 网页，那么您很可能是通过 OpenSSL 加密进行访问的。该库提供用于数据加密、解密、身份验证和数字签名验证的密码函数和协议。几乎任何需要保护 Web 服务器、电子邮件服务器、虚拟专用网络 (VPN) 和其他类型网络通信安全的地方都可以找到 OpenSSL。
看看上面的段落，您应该清楚 OpenSSL 对于互联网的正常运行有多么重要。它是许多计算机系统和应用程序安全基础设施的关键组件。它有助于保护敏感数据免遭未经授权的访问，并有助于确保网络通信的完整性和真实性。这就是为什么该库的维护者非常重视漏洞并尝试尽快修补它们。想象攻击者能够访问万维网基础设施的安全通信线路几乎是不可想象的。
在本文中，我们将研究促使 OpenSSL 于 3.0.7 年 2022 月发布补丁 XNUMX 的漏洞，并了解我们可以从 OpenSSL 维护人员处理该问题的方式中学到什么。
漏洞
25 年 2022 月 XNUMX 日，OpenSSL 项目发布了 advisory 警告新补丁即将发布以应对某些问题 危急 漏洞。 “关键”标签意味着这些漏洞可能会被利用，并且可能会窃取受影响服务器上的私钥和/或 RCE。
一周后，即 1 年 2022 月 3.0.7 日，OpenSSL 项目发布了新补丁 XNUMX 和 特定漏洞 他们的目标是修复。在此期间，漏洞的评级已从严重降级为“高严重性”。
那么，这些漏洞是什么？
CVE-2022-3602 – X.509 电子邮件地址 4 字节缓冲区溢出 – 在 X.509 证书验证中，特别是在名称约束检查中，可能会发生 XNUMX 个字节的缓冲区溢出。攻击者使用恶意电子邮件地址可能会溢出堆栈上由攻击者控制的四个字节。此缓冲区溢出可能会导致崩溃（导致拒绝服务）或潜在的远程代码执行。最初，它被归类为关键，但额外的测试表明，许多平台使用堆栈溢出保护措施来降低远程代码执行的风险。
CVE-2022-3786 – X.509 电子邮件地址可变长度缓冲区溢出 – 在 X.509 证书验证中，特别是在名称约束检查中，可能会发生缓冲区溢出。攻击者可以在证书中创建恶意电子邮件地址，以包含字符“.”（十进制数 46）的任意数量的字节填充堆栈。此缓冲区溢出可能会导致崩溃（导致拒绝服务）。
只是重申这些漏洞的严重性CISA（美国网络安全和基础设施安全局）发布了一份 advisory 与 OpenSSL 同一天，鼓励促使用户和管理员审查 OpenSSL 文档和升级（如果适用）到新补丁 3.0.7。
如前所述，运行 OpenSSL 的操作系统或邮件服务器上的 RCE（远程代码执行）会非常糟糕，因此仅揭示 一旦找到并提供了适当的补丁，就会发现漏洞。
接下来发生什么
最初的建议一发布，人们就开始争先恐后。 “不要惊慌”是一个常见的短语 当时 表明人们对 OpenSSL 具有严重性的新闻有多么认真 漏洞。
该公告发布后，所有相关利益相关者都在努力弄清楚他们的服务器、操作系统、应用程序、软件包等中使用的是哪个版本的 OpenSSL。除了内部 OpenSSL 使用之外，人们还需要弄清楚他们的第三个版本是否使用了 OpenSSL。第三方供应商或服务提供商使用易受攻击的 OpenSSL 版本。当时，如果您不确定自己使用的是哪个版本，或者不确定您的供应商和服务提供商使用的是哪个版本，则认为将应用程序脱机比冒潜在的 RCE 风险更安全。
由于该公告提前给出了补丁的时间表，让人们有时间弄清楚自己以及供应商和服务提供商的基础设施。我们的想法是规划所涉及的基础设施所需的一切，以便补丁一发布，就可以在需要时进行升级。
你会如何处理？
现在假设您是一家公司的工程师，据您所知，该公司的服务器使用 OpenSSL。一旦发布公告，您就需要找出库的哪个版本在哪里使用（包括任何遗留代码，如果仍在运行），然后为您的任何供应商或服务提供商找出同样的事情。
这是一个 斯博姆 真的可以派上用场。 SBOM 代表软件物料清单，它是构成特定软件产品的所有组件和软件依赖项的列表。 SBOM 通常包含所有软件组件的名称和版本（请参阅我的说明）、它们的来源和许可证以及与每个组件相关的任何已知漏洞或安全问题等信息。
如果您作为负责任的工程师，确保每个产品都有更新的 SBOM，那么只需在 SBOM 文件上运行搜索即可轻松找到在何处使用 OpenSSL 以及正在使用哪个版本。如果您还确保向与您公司合作的任何供应商或服务提供商索取更新的 SBOM，您也可以在那里进行相同的搜索。
由于您被告知这些漏洞仅影响 3.0.0 和 3.0.6 之间的版本，因此您所要做的就是检查您正在运行的版本，以了解哪些应用程序需要删除或使用新补丁（3.0.7）进行更新。 XNUMX.
只是为了展示使用 OpenSSL 的知名操作系统和企业应用程序的列表有多么广泛，请查看此 名单 作为公共服务发布，以便人们知道他们应该有多担心。
循证安全中心如何提供帮助
作为不断发展的网络安全格局的一部分，包括影响深远的 漏洞，我们目前正在见证 应用程序安全到软件供应链安全的演变。新一代的工具和技术已经被开发出来，试图解决这些问题。通过提供基于证据的持续代码安全保证平台，可以保证软件开发生命周期和软件组件的可靠性，自动化工具和解决方案可帮助组织实现新的安全级别。不断地找出依赖关系和漏洞，可以更轻松地修复或应用补丁（当补丁可用时）。
刻划式打标系统 是软件供应链安全中心。它收集证据并为通过 CI/CD 管道的每个构建提供证据。 Scribe 解决方案的目标是更容易遵守欧盟和美国的法规和最佳实践，以提高软件透明度并促进软件开发人员和用户之间的信任。该平台可以创建和共享全面的 SBOM 以及其他安全见解。此外，该平台可以确认您正在查看的构建符合 NIST 的 SSDF 框架和 SLSA 3 级要求。您不再需要摸索着试图弄清楚您在哪里使用哪个版本的库，因为您的每个构建都有一个带有 SBOM 的证据存储。现在，弄清楚它就像在文本文档中查找特定句子一样简单。
最后一句话：为下一次重大漏洞披露做好准备
补丁 3.0.7 的 OpenSSL 项目故事为我们提供了关于如何处理潜在严重漏洞的两个同样重要的观点。
从受影响的一方——可能受到这些漏洞影响的公司或项目，我们已经通报了透明度。他们不会立即披露可能造成伤害的信息，但一旦意识到问题，他们就会立即披露一切可以披露的信息。不仅如此，除了尽可能多的有关问题的信息之外，他们还提供了补救时间表。一旦出现补丁或补救措施，他们就会毫不犹豫地披露到底出了什么问题以及它可能如何被利用。这种透明度鼓励信任。用户和客户希望知道并感受到公司更关心他们，或者至少像关心公司的利润或董事会一样关心他们。
2014 年，OpenSSL 项目成为了一个名为“心脏出血漏洞' – OpenSSL 的 TLS/DTLS 实现中的一个严重缺陷，使攻击者可以从受影响的服务器获取加密密钥材料、密码和其他敏感信息等机密。 Heartbleed 展示了 OpenSSL 中的一个严重漏洞的影响范围，它影响了多种程序和 Linux 发行版。试图识别并修复每个易受攻击的系统让安全团队头痛了好几个月。实施像 SBOM 这样的工具，可以使软件更新和修补变得更快、更简单，这对任何公司的网络安全团队来说都是一个福音。
从修复方面来看，准确了解您必须使用的内容以及您在何处使用哪个版本的软件包对于能够处理任何此类潜在的紧急情况至关重要。以Log4J为例，在该漏洞被发现一年多后，一些公司仍在试图弄清楚他们是否受到该漏洞的影响。
事实上，您不仅需要担心您的软件和服务器，还需要担心您正在使用的任何第三方供应商的软件和服务器，或者您正在合作的任何服务提供商的软件和服务器，甚至使用 API 连接，这意味着我们，所有我们中的一些人确实需要在我们之间建立一个信任的网络。这种信任应尽可能依赖于确凿的证据。创建和跟踪您自己的以及与您有业务往来的任何公司的 SBOM，共享这些 SBOM，并在宣布和修复您发现的任何可利用漏洞时表现出诚意。
我们需要所有人共同努力，才能实现这样一个世界：分享此类证据就像在社交媒体上分享公司的最新公关一样司空见惯。如果没有这种信任，我们只是为下一个重大漏洞搭建舞台，从而破坏我们努力维护的互联基础设施。
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
