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 - 2020 -3602最初被标记为严重级别，因为维护者希望这个问题可以用于远程代码执行(堆栈溢出应该是这样)，但正因为如此，堆栈溢出非常有限(只有4字节覆盖)，许多供应商无法找到一个可以真正利用这个问题的公共环境。

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

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

也就是说，不能完全排除远程代码执行的可能性，因为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是

Alpine Edge(开发分支)
CentOS Stream 9(开发分支)
Fedora 36
卡莉2022.3
Linux Mint 21
红帽企业Linux 9
Ubuntu 22.04

请注意，有一些流行的开源项目使用OpenSSL 3。例如Node.js 17及更高版本，而这已经宣布安全更新将于11月1日上线，不过这个问题对Node.js用户的具体影响目前还不清楚。

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

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

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

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

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

如何解决这些问题?

CVE-2022-3602和CVE-2022-3786的建议修复方案是将OpenSSL更新到版本3.0.7．

Ubuntu 22.04用户可以将“openssl”包升级到版本3.0.2-0ubuntu1.7

红帽企业Linux 9用户可以将“openssl”包升级到版本openssl 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证书:

卷曲https://server-to-test.org 2>&1 | grep“证书要求”

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

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

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

Readelf -a [binary] | grep -i ossl_punycode_decode .使用实例

如何使用JFrog x射线检测CVE-2022-3602和CVE-2022-3786?

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

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

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

与JFrog安全研究保持最新

在我们的JFrog安全研究团队中跟踪最新的发现和技术更新安全研究博客文章在推特上@JFrogSecurity．

找到易受攻击的版本与JFrog x射线

除了通过我们的研究团队暴露新的安全漏洞和威胁，我们的JFrog x射线SCA工具通过自动安全扫描，为开发人员和安全团队提供方便地访问其软件的最新相关安全洞察。

CVE-2022-3602和CVE-2022-3786 -高度严重的OpenSSL漏洞终于发布