远程主机上安装的 OpenSSL 版本低于 3.0.3。因此，如公告 3.0.3 所述，该主机受到多个漏洞的影响。

  - 用于清空哈希表的 OPENSSL_LH_flush() 函数包含一个缺陷，该缺陷会破坏被删除的哈希表条目占用的内存的重用。解码证书或密钥时使用此函数。如果长期限进程定期解码证书或密钥，其内存使用量将无限制地扩展，并且该进程可能被操作系统终止，从而导致拒绝服务。
    遍历空哈希表条目也将花费越来越多的时间。通常，此类长期限进程可能是配置为接受客户端证书认证的 TLS 客户端或 TLS 服务器。OpenSSL 3.0 版本中添加了该函数，因此较早的版本不受此问题的影响。已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1473)

  - RC4-MD5 加密套件的 OpenSSL 3.0 实现错误地将 AAD 数据用作 MAC 密钥。
    这使得 MAC 密钥可轻松预测。攻击者可通过执行中间人攻击来利用此问题，从而修改从一个端点发送到 OpenSSL 3.0 接收方的数据，以便修改后的数据仍可通过 MAC 完整性检查。请注意，从 OpenSSL 3.0 端点发送到非 OpenSSL 3.0 端点的数据将始终被接收方拒绝，并且连接将在此时失败。许多应用程序协议要求首先将数据从客户端发送到服务器。
    因此，在这种情况下，与非 OpenSSL 3.0 客户端通信时，只有 OpenSSL 3.0 服务器会受到影响。如果两个端点均为 OpenSSL 3.0 ，则攻击者可修改双向发送的数据。在这种情况下，无论应用程序协议如何，客户端和服务器都可能受到影响。请注意，如果没有攻击者，此缺陷意味着使用此加密套件时，与非 OpenSSL 3.0 端点通信的 OpenSSL 3.0 端点将无法完成握手。数据的机密性不受此问题的影响，即攻击者无法解密已使用此加密套件加密的数据 - 他们只能对其进行修改。为使此攻击起作用，两个端点必须合法协商 RC4-MD5 加密套件。OpenSSL 3.0 中默认不编译此加密套件，且在默认提供程序或默认加密套件列表中不可用。如果已协商 TLSv1.3，则永远不会使用此加密套件。必须满足以下条件才能使 OpenSSL 3.0 端点使用此加密套件：1) OpenSSL 必须已使用（非默认）编译时选项 enable-weak-ssl-ciphers 进行编译 2) OpenSSL 必须已显式加载（通过应用程序代码或通过配置）旧提供程序 3) 加密套件必须已明确添加到加密套件列表 4) 必须将 libssl 安全级别设置为 0（默认为 1） 5) 必须协商低于 TLSv1.3 的 SSL/TLS 版本 6) 两个端点必须优先协商 RC4-MD5 加密套件，而不是两个端点共同拥有的任何其他加密套件；已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1434)

  - 函数 `OCSP_basic_verify` 验证 OCSP 响应中的签名者证书。在使用（非默认）标记 OCSP_NOCHECKS 的情况下，即使在响应签名证书验证失败的情况下，响应也将是肯定的（意味着验证成功）。预计 `OCSP_basic_verify` 的大多数用户将不会使用 OCSP_NOCHECKS 标记。在这种情况下，`OCSP_basic_verify` 函数将在证书验证失败时返回一个负值（表示一个致命错误）。在这种情况下，正常的预期返回值为 0。此问题也会影响命令行 OpenSSL ocsp 应用程序。当使用 -no_cert_checks 选项
    验证 ocsp 响应时，命令行应用程序将报告验证成功，即使它实际上已失败。在这种情况下，不正确的成功响应也会伴随显示失败的错误消息，并与表面上的成功结果相矛盾。已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1343)

  - c_rehash 脚本未正确审查 shell 元字符以防止命令注入。某些操作系统以自动执行的方式分发此脚本。在此类操作系统中，攻击者可以使用脚本的权限执行任意命令。使用 c_rehash 脚本被视为过时，应由 OpenSSL rehash 命令行工具取代。
    已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。已在 OpenSSL 1.1.1o 中修复（影响 1.1.1-1.1.1n）。
    已在 OpenSSL 1.0.2ze 中修复（影响 1.0.2-1.0.2zd）。(CVE-2022-1292)

请注意，Nessus 尚未测试这些问题，而是只依靠应用程序自我报告的版本号来判断。

远程主机上安装的 OpenSSL 版本低于 3.0.3-1。因此，如公告 ALAS2022-2022-104 所述，受到多个漏洞的影响。

  - c_rehash 脚本未正确审查 shell 元字符以防止命令注入。某些操作系统以自动执行的方式分发此脚本。在此类操作系统中，攻击者可以使用脚本的权限执行任意命令。使用 c_rehash 脚本被视为过时，应由 OpenSSL rehash 命令行工具取代。
    已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。已在 OpenSSL 1.1.1o 中修复（影响 1.1.1-1.1.1n）。
    已在 OpenSSL 1.0.2ze 中修复（影响 1.0.2-1.0.2zd）。(CVE-2022-1292)

  - 函数 `OCSP_basic_verify` 验证 OCSP 响应中的签名者证书。在使用（非默认）标记 OCSP_NOCHECKS 的情况下，即使在响应签名证书验证失败的情况下，响应也将是肯定的（意味着验证成功）。预计 `OCSP_basic_verify` 的大多数用户将不会使用 OCSP_NOCHECKS 标记。在这种情况下，`OCSP_basic_verify` 函数将在证书验证失败时返回一个负值（表示一个致命错误）。在这种情况下，正常的预期返回值为 0。此问题也会影响命令行 OpenSSL ocsp 应用程序。当使用 -no_cert_checks 选项
    验证 ocsp 响应时，命令行应用程序将报告验证成功，即使它实际上已失败。在这种情况下，不正确的成功响应也会伴随显示失败的错误消息，并与表面上的成功结果相矛盾。已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1343)

  - RC4-MD5 加密套件的 OpenSSL 3.0 实现错误地将 AAD 数据用作 MAC 密钥。
    这使得 MAC 密钥可轻松预测。攻击者可通过执行中间人攻击来利用此问题，从而修改从一个端点发送到 OpenSSL 3.0 接收方的数据，以便修改后的数据仍可通过 MAC 完整性检查。请注意，从 OpenSSL 3.0 端点发送到非 OpenSSL 3.0 端点的数据将始终被接收方拒绝，并且连接将在此时失败。许多应用程序协议要求首先将数据从客户端发送到服务器。
    因此，在这种情况下，与非 OpenSSL 3.0 客户端通信时，只有 OpenSSL 3.0 服务器会受到影响。如果两个端点均为 OpenSSL 3.0 ，则攻击者可修改双向发送的数据。在这种情况下，无论应用程序协议如何，客户端和服务器都可能受到影响。请注意，如果没有攻击者，此缺陷意味着使用此加密套件时，与非 OpenSSL 3.0 端点通信的 OpenSSL 3.0 端点将无法完成握手。数据的机密性不受此问题的影响，即攻击者无法解密已使用此加密套件加密的数据 - 他们只能对其进行修改。为使此攻击起作用，两个端点必须合法协商 RC4-MD5 加密套件。OpenSSL 3.0 中默认不编译此加密套件，且在默认提供程序或默认加密套件列表中不可用。如果已协商 TLSv1.3，则永远不会使用此加密套件。必须满足以下条件才能使 OpenSSL 3.0 端点使用此加密套件：1) OpenSSL 必须已使用（非默认）编译时选项 enable-weak-ssl-ciphers 进行编译 2) OpenSSL 必须已显式加载（通过应用程序代码或通过配置）旧提供程序 3) 加密套件必须已明确添加到加密套件列表 4) 必须将 libssl 安全级别设置为 0（默认为 1） 5) 必须协商低于 TLSv1.3 的 SSL/TLS 版本 6) 两个端点必须优先协商 RC4-MD5 加密套件，而不是两个端点共同拥有的任何其他加密套件；已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1434)

  - 用于清空哈希表的 OPENSSL_LH_flush() 函数包含一个缺陷，该缺陷会破坏被删除的哈希表条目占用的内存的重用。解码证书或密钥时使用此函数。如果长期限进程定期解码证书或密钥，其内存使用量将无限制地扩展，并且该进程可能被操作系统终止，从而导致拒绝服务。
    遍历空哈希表条目也将花费越来越多的时间。通常，此类长期限进程可能是配置为接受客户端证书认证的 TLS 客户端或 TLS 服务器。OpenSSL 3.0 版本中添加了该函数，因此较早的版本不受此问题的影响。已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1473)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Ubuntu 18.04 LTS/20.04 LTS/21.10/22.04 LTS 主机上安装的多个程序包受到 USN-5402-1 公告中提及的多个漏洞影响。

  - c_rehash 脚本未正确审查 shell 元字符以防止命令注入。某些操作系统以自动执行的方式分发此脚本。在此类操作系统中，攻击者可以使用脚本的权限执行任意命令。使用 c_rehash 脚本被视为过时，应由 OpenSSL rehash 命令行工具取代。
    已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。已在 OpenSSL 1.1.1o 中修复（影响 1.1.1-1.1.1n）。
    已在 OpenSSL 1.0.2ze 中修复（影响 1.0.2-1.0.2zd）。(CVE-2022-1292)

  - 函数 `OCSP_basic_verify` 验证 OCSP 响应中的签名者证书。在使用（非默认）标记 OCSP_NOCHECKS 的情况下，即使在响应签名证书验证失败的情况下，响应也将是肯定的（意味着验证成功）。预计 `OCSP_basic_verify` 的大多数用户将不会使用 OCSP_NOCHECKS 标记。在这种情况下，`OCSP_basic_verify` 函数将在证书验证失败时返回一个负值（表示一个致命错误）。在这种情况下，正常的预期返回值为 0。此问题也会影响命令行 OpenSSL ocsp 应用程序。当使用 -no_cert_checks 选项
    验证 ocsp 响应时，命令行应用程序将报告验证成功，即使它实际上已失败。在这种情况下，不正确的成功响应也会伴随显示失败的错误消息，并与表面上的成功结果相矛盾。已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1343)

  - RC4-MD5 加密套件的 OpenSSL 3.0 实现错误地将 AAD 数据用作 MAC 密钥。
    这使得 MAC 密钥可轻松预测。攻击者可通过执行中间人攻击来利用此问题，从而修改从一个端点发送到 OpenSSL 3.0 接收方的数据，以便修改后的数据仍可通过 MAC 完整性检查。请注意，从 OpenSSL 3.0 端点发送到非 OpenSSL 3.0 端点的数据将始终被接收方拒绝，并且连接将在此时失败。许多应用程序协议要求首先将数据从客户端发送到服务器。
    因此，在这种情况下，与非 OpenSSL 3.0 客户端通信时，只有 OpenSSL 3.0 服务器会受到影响。如果两个端点均为 OpenSSL 3.0 ，则攻击者可修改双向发送的数据。在这种情况下，无论应用程序协议如何，客户端和服务器都可能受到影响。请注意，如果没有攻击者，此缺陷意味着使用此加密套件时，与非 OpenSSL 3.0 端点通信的 OpenSSL 3.0 端点将无法完成握手。数据的机密性不受此问题的影响，即攻击者无法解密已使用此加密套件加密的数据 - 他们只能对其进行修改。为使此攻击起作用，两个端点必须合法协商 RC4-MD5 加密套件。OpenSSL 3.0 中默认不编译此加密套件，且在默认提供程序或默认加密套件列表中不可用。如果已协商 TLSv1.3，则永远不会使用此加密套件。必须满足以下条件才能使 OpenSSL 3.0 端点使用此加密套件：1) OpenSSL 必须已使用（非默认）编译时选项 enable-weak-ssl-ciphers 进行编译 2) OpenSSL 必须已显式加载（通过应用程序代码或通过配置）旧提供程序 3) 加密套件必须已明确添加到加密套件列表 4) 必须将 libssl 安全级别设置为 0（默认为 1） 5) 必须协商低于 TLSv1.3 的 SSL/TLS 版本 6) 两个端点必须优先协商 RC4-MD5 加密套件，而不是两个端点共同拥有的任何其他加密套件；已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1434)

  - 用于清空哈希表的 OPENSSL_LH_flush() 函数包含一个缺陷，该缺陷会破坏被删除的哈希表条目占用的内存的重用。解码证书或密钥时使用此函数。如果长期限进程定期解码证书或密钥，其内存使用量将无限制地扩展，并且该进程可能被操作系统终止，从而导致拒绝服务。
    遍历空哈希表条目也将花费越来越多的时间。通常，此类长期限进程可能是配置为接受客户端证书认证的 TLS 客户端或 TLS 服务器。OpenSSL 3.0 版本中添加了该函数，因此较早的版本不受此问题的影响。已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1473)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

因此，它受到 ALAS2022-2022-195 公告中提及的多个漏洞影响。

  - 除了 CVE-2022-1292 中发现的 c_rehash shell 命令注入之外，代码审查还发现了 c_rehash 脚本未正确审查 shell 元字符以防止命令注入的其他情况。修复 CVE-2022-1292 后，未发现脚本中的其他位置可能会将被哈希的证书文件名传递给通过 shell 执行的命令。某些操作系统以自动执行的方式分发此脚本。在此类操作系统中，攻击者可以使用脚本的权限执行任意命令。使用 c_rehash 脚本被视为过时，应由 OpenSSL rehash 命令行工具取代。已在 OpenSSL 3.0.4 中修复（影响 3.0.0、3.0.1、3.0.2、3.0.3）。已在 OpenSSL 1.1.1p 中修复（影响 1.1.1-1.1.1o）。已在 OpenSSL 1.0.2zf  中修复（影响 1.0.2-1.0.2ze）。(CVE-2022-2068)

  - 在某些情况下，使用 AES-NI 汇编优化实现的 32 位 x86 平台的 AES OCB 模式不会加密整个数据。这可能会显示内存中预先存在但未写入的 16 个字节数据。在就地加密的特殊情况下，将显示 16 个字节的纯文本。由于 OpenSSL 不支持用于 TLS 和 DTLS 的基于 OCB 的加密套件，因此它们都不会受到影响。已在 OpenSSL 3.0.5 中修复（影响 3.0.0-3.0.4）。在 OpenSSL 1.1.1q 中已修复（影响 1.1.1-1.1.1p）。(CVE-2022-2097)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

因此，它受到公告 ALAS2023-2023-051 中提及的多个漏洞影响。

  - 用于计算模平方根的 BN_mod_sqrt() 函数中包含一个缺陷，可导致其无限循环非质数模数。当在内部解析包含压缩形式的椭圆曲线公钥或具有以压缩形式编码的基点的显式椭圆曲线参数时，将会使用此函数。可以通过构建具有无效显式曲线参数的证书来触发无限循环。由于证书解析发生在证书签名验证之前，因此任何解析外部所提供证书的进程都可能遭受拒绝服务攻击。解析构建的私钥时也可能发生无限循环，因为其中可能包含显式椭圆曲线参数。因此，易受攻击的情况包括：- TLS 客户端使用服务器证书 - TLS 服务器使用客户端证书 - 从客户处获取证书或私钥的主机托管商 - 证书颁发机构解析用户的证书请求 - 解析 ASN.1 椭圆曲线参数以及使用 BN_mod_sqrt( ) 的任何其他应用程序，其中攻击者可控制易受此 DoS 问题影响的参数值。OpenSSL 1.0.2 版本在初始解析证书期间未解析公钥，这就使得触发无限循环变得稍难一些。但是，任何需要证书公钥的操作都将触发无限循环。特别是在证书签名验证期间，攻击者可使用自签名证书触发循环。OpenSSL 版本 1.0.2、1.1.1 和 3.0 会受此问题影响。2022 年 3 月 15 日发布的 1.1.1n 和 3.0.2 版本已解决此问题。已在 OpenSSL 3.0.2 中修复（影响 3.0.0、3.0.1）。已在 OpenSSL 1.1.1n 中修复（影响 1.1.1-1.1.1m）。已在 OpenSSL 1.0.2zd 中修复（影响 1.0.2-1.0.2zc）。(CVE-2022-0778)

  - c_rehash 脚本未正确审查 shell 元字符以防止命令注入。某些操作系统以自动执行的方式分发此脚本。在此类操作系统中，攻击者可以使用脚本的权限执行任意命令。使用 c_rehash 脚本被视为过时，应由 OpenSSL rehash 命令行工具取代。
    已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。已在 OpenSSL 1.1.1o 中修复（影响 1.1.1-1.1.1n）。
    已在 OpenSSL 1.0.2ze 中修复（影响 1.0.2-1.0.2zd）。(CVE-2022-1292)

  - 函数 `OCSP_basic_verify` 验证 OCSP 响应中的签名者证书。在使用（非默认）标记 OCSP_NOCHECKS 的情况下，即使在响应签名证书验证失败的情况下，响应也将是肯定的（意味着验证成功）。预计 `OCSP_basic_verify` 的大多数用户将不会使用 OCSP_NOCHECKS 标记。在这种情况下，`OCSP_basic_verify` 函数将在证书验证失败时返回一个负值（表示一个致命错误）。在这种情况下，正常的预期返回值为 0。此问题也会影响命令行 OpenSSL ocsp 应用程序。当使用 -no_cert_checks 选项
    验证 ocsp 响应时，命令行应用程序将报告验证成功，即使它实际上已失败。在这种情况下，不正确的成功响应也会伴随显示失败的错误消息，并与表面上的成功结果相矛盾。已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1343)

  - RC4-MD5 加密套件的 OpenSSL 3.0 实现错误地将 AAD 数据用作 MAC 密钥。
    这使得 MAC 密钥可轻松预测。攻击者可通过执行中间人攻击来利用此问题，从而修改从一个端点发送到 OpenSSL 3.0 接收方的数据，以便修改后的数据仍可通过 MAC 完整性检查。请注意，从 OpenSSL 3.0 端点发送到非 OpenSSL 3.0 端点的数据将始终被接收方拒绝，并且连接将在此时失败。许多应用程序协议要求首先将数据从客户端发送到服务器。
    因此，在这种情况下，与非 OpenSSL 3.0 客户端通信时，只有 OpenSSL 3.0 服务器会受到影响。如果两个端点均为 OpenSSL 3.0 ，则攻击者可修改双向发送的数据。在这种情况下，无论应用程序协议如何，客户端和服务器都可能受到影响。请注意，如果没有攻击者，此缺陷意味着使用此加密套件时，与非 OpenSSL 3.0 端点通信的 OpenSSL 3.0 端点将无法完成握手。数据的机密性不受此问题的影响，即攻击者无法解密已使用此加密套件加密的数据 - 他们只能对其进行修改。为使此攻击起作用，两个端点必须合法协商 RC4-MD5 加密套件。OpenSSL 3.0 中默认不编译此加密套件，且在默认提供程序或默认加密套件列表中不可用。如果已协商 TLSv1.3，则永远不会使用此加密套件。必须满足以下条件才能使 OpenSSL 3.0 端点使用此加密套件：1) OpenSSL 必须已使用（非默认）编译时选项 enable-weak-ssl-ciphers 进行编译 2) OpenSSL 必须已显式加载（通过应用程序代码或通过配置）旧提供程序 3) 加密套件必须已明确添加到加密套件列表 4) 必须将 libssl 安全级别设置为 0（默认为 1） 5) 必须协商低于 TLSv1.3 的 SSL/TLS 版本 6) 两个端点必须优先协商 RC4-MD5 加密套件，而不是两个端点共同拥有的任何其他加密套件；已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1434)

  - 用于清空哈希表的 OPENSSL_LH_flush() 函数包含一个缺陷，该缺陷会破坏被删除的哈希表条目占用的内存的重用。解码证书或密钥时使用此函数。如果长期限进程定期解码证书或密钥，其内存使用量将无限制地扩展，并且该进程可能被操作系统终止，从而导致拒绝服务。
    遍历空哈希表条目也将花费越来越多的时间。通常，此类长期限进程可能是配置为接受客户端证书认证的 TLS 客户端或 TLS 服务器。OpenSSL 3.0 版本中添加了该函数，因此较早的版本不受此问题的影响。已在 OpenSSL 3.0.3 中修复（影响 3.0.0、3.0.1、3.0.2）。(CVE-2022-1473)

  - 除了 CVE-2022-1292 中发现的 c_rehash shell 命令注入之外，代码审查还发现了 c_rehash 脚本未正确审查 shell 元字符以防止命令注入的其他情况。修复 CVE-2022-1292 后，未发现脚本中的其他位置可能会将被哈希的证书文件名传递给通过 shell 执行的命令。某些操作系统以自动执行的方式分发此脚本。在此类操作系统中，攻击者可以使用脚本的权限执行任意命令。使用 c_rehash 脚本被视为过时，应由 OpenSSL rehash 命令行工具取代。已在 OpenSSL 3.0.4 中修复（影响 3.0.0、3.0.1、3.0.2、3.0.3）。已在 OpenSSL 1.1.1p 中修复（影响 1.1.1-1.1.1o）。已在 OpenSSL 1.0.2zf 中修复（影响 1.0.2-1.0.2ze）。(CVE-2022-2068)

  - 在某些情况下，使用 AES-NI 汇编优化实现的 32 位 x86 平台的 AES OCB 模式不会加密整个数据。这可能会显示内存中预先存在但未写入的 16 个字节数据。在就地加密的特殊情况下，将显示 16 个字节的纯文本。由于 OpenSSL 不支持用于 TLS 和 DTLS 的基于 OCB 的加密套件，因此它们都不会受到影响。已在 OpenSSL 3.0.5 中修复（影响 3.0.0-3.0.4）。在 OpenSSL 1.1.1q 中已修复（影响 1.1.1-1.1.1p）。(CVE-2022-2097)

  - 缓冲区溢出可在 X.509 证书验证中触发，在名称限制检查中更是如此。请注意，这会在证书链签名验证之后发生，并且需要 CA 签署恶意证书，或者要求应用程序在未能构建到受信任颁发者的路径的情况下继续证书验证。攻击者可以构建恶意电子邮件地址，使堆栈上四个由攻击者控制的字节溢出。此缓冲区溢出可能会导致崩溃（造成拒绝服务）或远程代码执行。许多平台实现了堆栈溢出保护，可降低远程代码执行的风险。可根据任何给定平台/编译器的堆栈布局进一步缓解此风险。 CVE-2022-3602 的预先公告将此问题描述为“危急”。基于上述一些缓解因素的进一步分析可将此问题降级为“高危”。仍建议用户尽快升级到新版本。在 TLS 客户端中，这可通过连接到恶意服务器来触发。
    在 TLS 服务器中，如果服务器请求客户端认证并连接了恶意客户端，就会触发此问题。已在 OpenSSL 3.0.7 中修复（影响 3.0.0、3.0.1、3.0.2、3.0.3、3.0.4、3.0.5、3.0.6、CVE-2022-3602）。

  - 缓冲区溢出可在 X.509 证书验证中触发，在名称限制检查中更是如此。请注意，这会在证书链签名验证之后发生，并且需要 CA 签署恶意证书，或者要求应用程序在未能构建到受信任颁发者的路径的情况下继续证书验证。攻击者可特制证书中的恶意电子邮件地址，以在堆栈上溢出包含“.”字符（十进制 46）的任意数量的字节。此缓冲区溢出可能会导致崩溃（造成拒绝服务）。在 TLS 客户端中，这可通过连接到恶意服务器来触发。在 TLS 服务器中，如果服务器请求客户端认证并连接了恶意客户端，就会触发此问题。(CVE-2022-3786)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
160473	OpenSSL 3.0.0 < 3.0.3 多种漏洞	Nessus	Web Servers	2022/5/3	2024/1/8	critical
164775	Amazon Linux 2022：openssl (ALAS2022-2022-104)	Nessus	Amazon Linux Local Security Checks	2022/9/7	2023/10/12	critical
160502	Ubuntu 18.04 LTS / 20.04 LTS / 22.04 LTS：OpenSSL 漏洞 (USN-5402-1)	Nessus	Ubuntu Local Security Checks	2022/5/4	2023/10/16	critical
167019	Amazon Linux 2022：(ALAS2022-2022-195)	Nessus	Amazon Linux Local Security Checks	2022/11/5	2023/10/5	critical
173139	Amazon Linux 2023：openssl、openssl-devel、openssl-libs (ALAS2023-2023-051)	Nessus	Amazon Linux Local Security Checks	2023/3/21	2023/4/21	critical

检测

插件搜索

critical

critical

critical

critical

critical