远程 Redhat Enterprise Linux 9 主机上安装的程序包受到 RHSA-2023: 0946 公告中提及的多个漏洞影响。

  - 读取缓冲区溢出可在 X.509 证书验证中触发，在名称限制检查中更是如此。请注意，这会在证书链签名验证之后发生，并且需要 CA 签署恶意证书，或者要求应用程序在未能构建到受信任颁发者的路径的情况下继续证书验证。读取缓冲区溢出可能导致崩溃，进而导致拒绝服务攻击。理论上，该漏洞也可能导致私有内存内容（如私钥或敏感纯文本）泄露，尽管截至本公告发布之时，我们尚未发现任何会有效导致内存内容泄露的漏洞。在 TLS 客户端中，这可通过连接到恶意服务器来触发。在 TLS 服务器中，如果服务器请求客户端认证并连接了恶意客户端，就会触发此问题。(CVE-2022-4203)

  - OpenSSL RSA 解密实现中存在一个基于时序的边信道，足以用于在 Bleichenbacher 式攻击中跨网络恢复明文。若要成功解密，攻击者必须能够发送大量的测试消息进行解密。
    此漏洞会影响所有 RSA 填充模式：PKCS#1 v1.5、RSA-OEAP 和 RSASVE。例如，在 TLS 连接中，客户端通常会使用 RSA 向服务器发送经过加密的预主密钥。如果攻击者能够发现客户端与服务器之间的真正连接，则可向服务器发送测试消息并记录消息处理用时。在发送足够多的消息后，攻击者可恢复用于原始连接的预主密钥，进而解密通过该连接发送的应用程序数据。(CVE-2022-4304)

  - 函数 PEM_read_bio_ex() 会读取 BIO 中的 PEM 文件，并解析和解码名称（例如，
    CERTIFICATE）、任何标头数据和负载数据。如果函数成功完成上述操作，则会使用指向包含相关解码数据的缓冲区的指针填充 name_out、header 和 data 参数。
    调用程序负责释放这些缓冲区。构建的 PEM 文件中可能不会含有负载数据。在这种情况下，PEM_read_bio_ex() 将返回故障代码，但会使用指向已完成释放的缓冲区的指针填充标头参数。如果调用程序也释放了此缓冲区，则会发生双重释放。这很有可能会导致崩溃。如果攻击者能够提供恶意 PEM 文件以进行解析，则可实现拒绝服务攻击。函数 PEM_read_bio() 和 PEM_read() 是对 PEM_read_bio_ex() 的简单封装，因此这两个函数也会直接受到影响。这些函数也会受到许多其他 OpenSSL 函数的间接调用，包括同样容易受到攻击的 PEM_X509_INFO_read_bio_ex() 和 SSL_CTX_use_serverinfo_file()。有时，在 OpenSSL 内部使用这些函数不易受到攻击，因为如果 PEM_read_bio_ex() 返回故障代码，调用程序便不会释放标头参数。这些位置包括 PEM_read_bio_TYPE() 函数以及 OpenSSL 3.0 中引入的解码器。OpenSSL asn1parse 命令行应用程序也会受到此问题的影响。(CVE-2022-4450)

  - 公共 API 函数 BIO_new_NDEF 是辅助函数，用于通过 BIO 对 ASN.1 数据作流式处理。该函数主要在 OpenSSL 内部用于为 SMIME、CMS 和 PKCS7 提供流式传输功能支持，但也可能由最终用户应用程序直接调用。该函数从调用程序接收 BIO，在其前面附加一个新的 BIO_f_asn1 filter BIO 以形成 BIO 链，然后将 BIO 链的新标头返回给调用程序。在某些情况下（例如 CMS Recipient 公钥无效时），新的 filter BIO 将被释放，而该函数则会返回表示失败的 NULL 结果。但是，在这种情况下，由于 BIO 链未正确清理，所以调用程序传递的 BIO 仍会保留指向之前已释放的 filter BIO 的内部指针。如果调用程序随后继续调用 BIO 上的 BIO_pop()，则会发生释放后使用。这很有可能会导致崩溃。这种情况直接发生在内部函数 B64_write_ASN1() 中，不仅可能导致 BIO_new_NDEF() 被调用，还会导致 BIO 上的 BIO_pop() 在随后被调用。此内部函数依次由公共 API 函数 PEM_write_bio_ASN1_stream、PEM_write_bio_CMS_stream、PEM_write_bio_PKCS7_stream、SMIME_write_ASN1、SMIME_write_CMS 和 SMIME_write_PKCS7 调用。可能受到此问题影响的其他公共 API 函数包括 i2d_ASN1_bio_stream、BIO_new_CMS、BIO_new_PKCS7、i2d_CMS_bio_stream 和 i2d_PKCS7_bio_stream。OpenSSL CMS 和 S/MIME 命令行应用程序同样会受到影响。(CVE-2023-0215)

  - 当应用程序尝试使用 d2i_PKCS7()、d2i_PKCS7_bio() 或 d2i_PKCS7_fp() 函数加载畸形 PKCS7 数据时，会触发读取时的无效指针取消引用。取消引用会导致应用程序崩溃，进而导致拒绝服务攻击。OpenSSL 中的 TLS 实现不会调用此函数，但是第三方应用程序可能会在不受信任的数据上调用这些函数。
    (CVE-2023-0216)

  - 当应用程序尝试使用 EVP_PKEY_public_check() 函数检查畸形 DSA 公钥时，会触发读取时的无效指针取消引用。这很有可能会导致应用程序崩溃。
    由于此函数可在来自不受信任源来源的公钥上调用，因而攻击者可利用此漏洞造成拒绝服务攻击。OpenSSL 中的 TLS 实现不会调用此函数，但如果诸如 FIPS 140-3之类的标准中有他安全要求，应用程序可能会调用该函数。(CVE-2023-0217)

  - 存在一个与 X.509 GeneralName 内的 X.400 地址处理相关的类型混淆漏洞。
    X.400 地址被解析为 ASN1_STRING，但 GENERAL_NAME 的公共结构定义错误地将 x400Address 字段的类型指定为 ASN1_TYPE。随后，按照 OpenSSL 函数 GENERAL_NAME_cmp 的解读，此字段应为 ASN1_TYPE 而不是 ASN1_STRING。CRL 检查启用（即应用程序设置 X509_V_FLAG_CRL_CHECK 标记）后，攻击者利用此漏洞可向 memcmp 调用传递任意指针，让指针能够读取内存内容或引起拒绝服务。在大多数情况下，攻击者需要同时提供证书链和 CRL 才能发起攻击，而这两者都不需要具有有效的签名。如果攻击者仅控制其中一个输入，则另一个输入必须已包含作为 CRL 分发点的 X.400 地址，但这种情况并不常见。因此，此漏洞最有可能只影响本身已实现通过网络检索 CRL 功能的应用程序。(CVE-2023-0286)

  - 在 PKCS7 signed 或 signedAndEnveloped 数据上验证签名时，会出现空指针取消引用漏洞。如果 OpenSSL 库中存在用于签名的哈希算法，但哈希算法的实现不可用，摘要初始化将无法进行。缺少对初始化函数的返回值的检查很可能会在以后导致摘要 API 的无效使用，进而导致崩溃。算法不可用的原因有二，其一是使用了启用 FIPS 配置的提供程序，更常见的原因是未加载旧版提供程序。
    PKCS7 数据由 SMIME 库调用以及时间戳 (TS) 库调用处理。OpenSSL 中的 TLS 实现不会调用这些函数，但如果三方应用程序调用这些函数来验证不受信任数据上的签名，这些应用程序则会受到影响。(CVE-2023-0401)

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

检测

RHEL 9：openssl（RHSA-2023：0946)

high Nessus 插件 ID 171973

版本 1.6

版本 1.5

版本 1.4

版本 1.4

版本 1.3

版本 1.2

版本 1.1

版本 1.0

版本 1.6 Apr 28, 2024, 2:25 PM Detection (updated detection logic) Plugin metadata Reference Plugin Feed: 202404281425
版本 1.5 Jan 26, 2024, 11:18 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202401262318
版本 1.4 May 24, 2023, 8:43 PM Logic Changes (Added support for ppc64le architecture) Plugin Feed: 202305242043
版本 1.4 Jan 26, 2024, 9:00 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202401262100
版本 1.3 Mar 31, 2023, 10:15 AM IAVM reference Plugin Feed: 202303311015
版本 1.2 Mar 22, 2023, 4:37 PM CVSSv2 score source (changed from "CVE-2022-4203" to "CVE-2023-0286") CVSS metrics ("CVSSv2 score" changed from "9.4" to "7.1". "CVSSv2 score" changed from "9.4" to "7.1". "CVSSv2 score" changed from "9.4" to "7.1". "CVSSv2 vector" changed from "CVSS2#AV:N/AC:L/Au:N/C:C/I:N/A:C" to "CVSS2#AV:N/AC:H/Au:N/C:C/I:N/A:C". "CVSSv3 score" changed from "9.1" to "7.4". "CVSSv3 vector" changed from "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H" to "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H". "CVSSv2 vector" changed from "CVSS2#AV:N/AC:L/Au:N/C:C/I:N/A:C" to "CVSS2#AV:N/AC:H/Au:N/C:C/I:N/A:C". "CVSSv3 score" changed from "9.1" to "7.4". "CVSSv3 vector" changed from "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H" to "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H") CVSSv3 score source (set to "CVE-2023-0286") Plugin Feed: 202303221637
版本 1.1 Mar 7, 2023, 2:00 PM CVSSv3 score source (set to "CVE-2022-4203") CVSSv2 score source (changed from "CVE-2023-0286" to "CVE-2022-4203") CVSS metrics ("CVSSv2 score" changed from "7.1" to "9.4". "CVSSv2 score" changed from "7.1" to "9.4". "CVSSv2 score" changed from "7.1" to "9.4". "CVSSv3 score" changed from "7.4" to "9.1". "CVSSv2 vector" changed from "CVSS2#AV:N/AC:H/Au:N/C:C/I:N/A:C" to "CVSS2#AV:N/AC:L/Au:N/C:C/I:N/A:C". "CVSSv3 vector" changed from "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H" to "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H". "CVSSv3 score" changed from "7.4" to "9.1". "CVSSv2 vector" changed from "CVSS2#AV:N/AC:H/Au:N/C:C/I:N/A:C" to "CVSS2#AV:N/AC:L/Au:N/C:C/I:N/A:C". "CVSSv3 vector" changed from "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H" to "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H". "CVSSv3 score" changed from "7.4" to "9.1". "CVSSv2 vector" changed from "CVSS2#AV:N/AC:H/Au:N/C:C/I:N/A:C" to "CVSS2#AV:N/AC:L/Au:N/C:C/I:N/A:C". "CVSSv3 vector" changed from "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H" to "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H". "CVSSv3 score" changed from "7.4" to "9.1") Plugin Feed: 202303071400
版本 1.0 Feb 28, 2023, 8:05 PM New Plugin Feed: 202302282005