CVE-2022-3602和CVE-2022-3786 -高严重性OpenSSL漏洞最终公布

我们是怎么走到这一步的?

10月25日，OpenSSL团队宣布OpenSSL 3.0.7将包含对影响OpenSSL 3.x的严重漏洞的修复。有关漏洞的全部细节一直被封锁，直到11月1日．

由于OpenSSL严重问题的罕见性和OpenSSL的压倒性流行，社交媒体上充斥着关于这个问题的消息，期待一个“Log4Shell”级别的事件。

然而，当漏洞细节发布时，似乎这些问题并不像最初想象的那么糟糕。

两个漏洞而不是一个，降低了严重性

随着官方咨询发布后，我们惊讶地发现OpenSSL 3.0.7 -中修复了两个漏洞

• CVE-2022-3602——在验证TLS (X.509)证书时触发的4字节堆栈缓冲区溢出
• CVE-2022-3786—在验证TLS (X.509)证书时可以触发任意长度的堆栈缓冲区溢出，但不让攻击者控制溢出的数据

更令人惊讶的是，这两个漏洞都被评为高严重漏洞，不像预先宣布的至少有一个是至关重要的严重的问题。

对于CVE-2022-3786，很明显，这个问题不会导致远程代码执行(攻击者不控制溢出的数据)，因此高严重性评级是有意义的，但对于CVE-2022-3602，这是一个更难回答的问题。

为什么CVE-2022-3602的严重程度被降级了?

看着官方网站最初的开发尝试为这个问题提供了一个更好的答案。似乎CVE-2022-3602最初被标记为严重程度，因为维护者期望这个问题可以被用于远程代码执行(堆栈溢出应该是)，但正因为如此，堆栈溢出是非常有限的(只有4字节的覆盖)，许多供应商无法找到一个可以实际利用这个问题的通用环境。

这一点还将作更详细的讨论“Anti-PoC”这表明这个问题不能在常见的Linux配置中被利用，由于溢出-

1. 覆盖填充字节，这没有效果，或者
2. 重写重写函数中不重要的变量

也就是说，不能完全排除远程代码执行的可能性，因为OpenSSL可能会在大量配置和大量体系结构中进行编译，其中一种体系结构可能满足利用的先决条件。

同样值得注意的是，任何运行OpenSSL 3的机器。x(a fairly new version, as noted) will also likely be using stack-buffer-overflow mitigations such asASLR和StackGuard．因此，攻击者必须找到额外的0天信息泄露漏洞，以克服这些缓解措施并实现完整的RCE利用。

谁容易受到这些问题的影响?

OpenSSL团队确认只有OpenSSL 3。xversions are affected, specifically OpenSSL 3.0.0 – 3.0.7.

幸运的是3。xis a newer branch of OpenSSL, which was released approx. 1 year ago (Sep. 2021) and hasn’t been widely adopted yet.

使用OpenSSL 3的流行发行版。x是

• 高山边缘(发展分支)
• CentOS Stream 9(开发分支)
• Fedora 36
• 卡莉2022.3
• Linux Mint 21
• Red Hat Enterprise Linux 9
• Ubuntu 22.04

请注意，已知有一些流行的开源项目使用OpenSSL 3。例如Node.js 17及以后的版本宣布安全更新也将在11月1日发布，尽管目前还不知道这个问题对Node.js用户的确切影响。

此外，已证实LibreSSL不受此问题影响．

有受此问题影响(或不受影响)的常见第三方软件的其他列表，特别是受NCSC-NL和一个众包列表。

这些问题的攻击场景是什么?

因为这两个漏洞都需要一个正确签名的TLS证书来由OpenSSL 3进行验证。(OpenSSL TLS客户端或TLS服务器)最可能的攻击场景是

1. 启用了OpenSSL 3.xTLS服务器接受客户端证书(启用TLS客户端身份验证)。这通常是TLS服务器的非默认选项。如果假设RCE不太可能发生，这是更严重的情况。
2. 启用了OpenSSL 3.xTLS客户访问恶意TLS服务器，例如，如果浏览器通过网络钓鱼攻击跟踪到恶意网站的链接。

如何解决这些问题?

针对CVE-2022-3602和CVE-2022-3786的建议修复是将OpenSSL更新为版本3.0.7．

Ubuntu 22.04用户可以将“openssl”包升级到version3.0.2-0ubuntu1.7

Red Hat Enterprise Linux 9用户可以将“openssl”包升级到versionopenssl el9_0——3.0.1 - 43.

这些问题可以在不升级OpenSSL的情况下得到缓解吗?

如果我们目前假设RCE是不可能的(或者至少是非常不可能的)，那么针对TLS服务器的CVE-2022-3786的利用是唯一剩下的令人担忧的问题，因为它会导致活跃的TLS服务拒绝服务(使用该漏洞使单个TLS客户端崩溃则不那么令人担忧)。

如前所述，最可能的攻击媒介是恶意客户端向OpenSSL 3发送TLS客户端证书。基于x的TLS服务器是否愿意接受客户端证书．

幸运的是，绝大多数TLS服务器默认情况下不接受或验证客户端证书，因此，如果您的特定TLS服务器是否配置为验证客户端证书，可以通过暂时禁用对客户端证书的验证来缓解该漏洞。

这个过程对于每个TLS服务器都是不同的，但是例如在Node.js TLS服务器上

Var HTTPS = require(' HTTPS ');Var fs = require('fs');var options = {key: fs.readFileSync('/etc/pki/tls/private/ca.key')， cert: fs.readFileSync('/etc/pki/tls/certs/ca.crt')， //开启客户端证书认证!requestCert: true，…https。createServer(选项,…

改变requestCert来假会缓解这个问题。

如何检查服务器是否受到这些问题的影响?

根据上一节，可以通过使用curl轻松查询TLS服务器以检查它们是否需要TLS证书:

Curl https://server-to-test.org 2>&1 | grep "certificate required"

“需要证书”的回答强烈暗示服务器将尝试验证客户端证书，使其远程容易受到CVE-2022-3602和CVE-2022-3786的攻击。在这种情况下，我们强烈建议您将OpenSSL版本升级到3.0.7，以避免DoS。

否定答案并不能保证服务器不受攻击，因为服务器可能接受TLS客户端证书，但不接受需要他们。

除了上述检查之外，还可以通过简单的readelf调用来检查静态链接的二进制文件是否包含易受攻击的函数:

Readelf -a [binary] | grep -i ossl_punycode_decode

如何使用JFrog Xray检测CVE-2022-3602和CVE-2022-3786?

JFrog Xray可以通过常规漏洞扫描检测CVE-2022-3602和CVE-2022-3786，并直接从我们的安全研究团队提供有关这些漏洞的额外信息。

Ubuntu、Red Hat、Alpine和非发行版特定的镜像都支持扫描。

像往常一样，用JFrog CLI或IDE插件完全支持。

与JFrog安全研究保持同步

关注JFrog安全研究团队的最新发现和技术更新安全研究博客文章在推特上@JFrogSecurity．

使用JFrog Xray查找易受攻击的版本

除了通过我们的研究团队暴露新的安全漏洞和威胁之外，我们的JFrog Xray SCA工具通过自动安全扫描，开发人员和安全团队可以轻松访问其软件的最新相关安全见解。