Universal Forwarders 8.2.0 < 8.2.12、9.0.0 < 9.0.6、9.1.0 < 9.1.1 (SVD-2023-0809)
critical Nessus 插件 ID 194926
语言：
简介
远程 Web 服务器主机上运行的应用程序受到一个漏洞的影响描述
远程主机上安装的 Splunk 版本低于测试版本。因此，它受到 SVD-2023-0809 公告中提及的漏洞的影响。- Google Chrome 91.0.4472.164 之前版本的 Blink XSLT 中存在释放后使用漏洞，远程攻击者可能利用此漏洞，通过特制的 HTML 页面利用堆损坏。(CVE-2021-30560)
- 在低于 v8.0.0 版的 libcurl 中存在身份验证绕过漏洞，尽管修改了 SSH 选项，但该漏洞仍会重用之前建立的 SSH 连接，而不是阻止重用。libcurl 维护一个之前使用过的连接池，以在配置匹配时将其重新用于后续传输。但是，配置检查中忽略了两个 SSH 设置，从而使这两个设置可以轻松匹配，进而可能导致重复使用不适当的连接。(CVE-2023-27538)
- 在低于 8.0.0 版的 libcurl 中，若在单独的句柄之间共享 HSTS 数据，则会出现双重释放漏洞。
引入此共享时未考虑在单独的线程之间执行此共享，但文档未对此情况进行说明。由于缺少互斥体或线程锁，共享相同 HSTS 数据的两个线程可能以执行双重释放或释放后使用而告终。(CVE-2023-27537)
- 在低于 8.0.0 版的 libcurl 的连接重用功能中存在认证绕过漏洞，由于未能检查 CURLOPT_GSSAPI_DELEGATION 选项中的更改，该漏洞可重用之前建立的连接。此漏洞会影响 krb5/kerberos/negotiate/GSSAPI 传输，并可能导致对敏感信息进行未经授权的访问。最安全的做法是在 CURLOPT_GSSAPI_DELEGATION 选项已更改时不重复使用连接。(CVE-2023-27536)
- 在低于 8.0.0 版的 libcurl 中，FTP 连接重用功能中存在一个认证绕过漏洞，可导致在后续传输期间使用错误的凭据。之前创建的连接如果与当前设置匹配，则会保留在连接池中以供重用。但是，某些 FTP 设置（例如 CURLOPT_FTP_ACCOUNT、CURLOPT_FTP_ALTERNATIVE_TO_USER、CURLOPT_FTP_SSL_CCC 和 CURLOPT_USE_SSL）未包含在配置匹配检查中，进而导致它们过于容易匹配。这可能导致 libcurl 在执行传输时使用错误的凭据，从而可能允许对敏感信息进行未经授权的访问。(CVE-2023-27535)
- 在低于 8.0.0 版的 curl 的 SFTP 实现中存在一个路径遍历漏洞，除波浪号 (~) 字符预期用作第一个元素以指示相对于用户主目录的路径外，该漏洞会导致波浪号 (~) 字符在第一个路径元素中用作前缀时被错误替换。攻击者可在使用特定用户访问服务器时，通过构建类似 /~2/foo 的路径，利用此缺陷绕过过滤或执行任意代码。(CVE-2023-27534)
- 使用 TELNET 协议进行通信期间，低于 8.0 版的 curl 的输入验证存在漏洞，可能允许攻击者在服务器协商期间传递恶意构建的用户名和 telnet 选项。
缺少正确的输入以清理允许攻击者在没有应用程序意图的情况下发送内容或执行选项协商。如果应用程序允许用户输入，则攻击者可利用此漏洞，进而能够在系统上执行任意代码。(CVE-2023-27533)
- 在基于链接的 HTTP 压缩算法且版本低于 v7.88.0 的 curl 中存在配置资源时无限制或节流的漏洞，这意味着服务器响应可被多次压缩，并且可能使用不同的算法。已针对此解压缩链中可接受的链接数量设置上限，但该上限基于每个标题设置，所以恶意服务器仅使用许多标头即可插入几乎无数量上限的压缩步骤。使用此类解压缩链可导致 malloc 炸弹，使 curl 最终消耗大量分配的堆内存，或尝试并返回内存不足错误。(CVE-2023-23916)
- curl <v7.88.0 中存在敏感信息明文传输漏洞，当同时请求多个 URL 时，可能导致 HSTS 功能表现不当。如使用 HSTS 支持，即使在 URL 中提供了 HTTP，仍可指示 curl 使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。然而，当并行完成多个传输时，此 HSTS 机制会出人意料地失败，因为 HSTS 缓存文件被最近完成的传输覆盖。之后向之前主机名的仅 HTTP 传输将*不会*正确升级到 HSTS。
(CVE-2023-23915)
- curl <v7.88.0 中存在敏感信息明文传输漏洞，当连续请求多个 URL 时，可能导致 HSTS 功能失败。如使用 HSTS 支持，即使在 URL 中提供了 HTTP，仍可指示 curl 使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。然而，令人意外的是，当在相同命令行上完成时，此 HSTS 机制会被后续传输忽略，因为状态不会正确维持下去。 (CVE-2023-23914)
- curl <7.87.0 中存在释放后使用漏洞。可要求 Curl 通过 HTTP 代理*传输*其支持的几乎所有协议。HTTP 代理可以（而且经常会）拒绝此类传输操作。
如果传输特定协议 SMB 或 TELNET 被拒，Curl 会在其传输关闭代码路径中使用已释放的堆分配结构。(CVE-2022-43552)
- curl <7.87.0 HSTS 检查中存在漏洞，攻击者可绕过检查以诱骗程序继续使用 HTTP。
如使用 HSTS 支持，即使在 URL 中提供了 HTTP，仍可指示 curl 使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。但是，如果给定 URL 中的主机名首先使用在 IDN 转换过程中被替换为 ASCII 对应项的 IDN 字符，则可以绕过 HSTS 机制。就像使用 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) 字符，而不是通用的 ASCII 句号 (U+002E)“.”。然后在后续请求中，程序不会检测 HSTS 状态并进行明文传输。这是因为它会存储经 IDN 编码的信息，但查找经 IDN 解码的信息。(CVE-2022-43551)
- 在 7.86.0 版之前的 curl 中，可绕过 HSTS 检查以诱骗其继续使用 HTTP。使用其 HSTS 支持，即使在 URL 中提供 HTTP 时，也可指示 curl 直接使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。如果给定 URL 中的主机名使用在 IDN 转换过程中被 ASCII 对应项替换的 IDN 字符，则可绕过此机制。例如使用字符 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) 而不是通用 ASCII 句号 U+002E (.)。
低于 7.77.0 2021-05-26 的版本均受影响。(CVE-2022-42916)
- 在 7.86.0 版之前的 curl 中存在双重释放。如果指示 curl 使用 HTTP 代理进行具有非 HTTP URL 的传输，它会通过向代理发出 CONNECT 请求来与远程服务器建立连接，然后使协议的其余部分通过隧道。HTTP 代理可能拒绝此请求（HTTP 代理通常只允许传出连接至特定端口号，例如 HTTPS 的 443），而向客户端返回非 200 状态代码。由于错误/清理处理中的缺陷，如果在 URL 中使用以下方案之一进行传输，则这可能在 curl 中触发双重释放：dict、gopher、gophers、ldap、ldaps、rtmp、rtmps 或 telnet。低于 7.77.0 的版本均受影响。(CVE-2022-42915)
- 可指示 curl 解析 `.netrc` 文件以获取凭据。如果该文件以具有 4095 个连续非空白字符且无换行符的行结尾，则 curl 将首先读取超过基于堆栈的缓冲区的末尾，如果是 readworks，则写入一个超出其边界的零字节。在大多数情况下此问题会造成段错误或类似问题，但不同的环境也可能造成不同的结果。如果恶意用户可以向应用程序提供自定义 netrc 文件，或以其他方式影响其内容，则此缺陷可被用作拒绝服务。(CVE-2022-35260)
- 在进行 HTTP(S) 传输时，如果之前使用相同的句柄发出 `PUT` 请求（使用读取回调 (`CURLOPT_READFUNCTION`)），即使设置了 `CURLOPT_POSTFIELDS` 选项，libcurl 可能会错误地使用该回调来请求发送数据。此缺陷可能会使应用程序发生意外并导致其行为不当，并在后续的 `POST` 请求中发送错误的数据或使用释放后的内存或类似内容。从 PUT 更改为 POST 时，重用句柄的逻辑中存在此问题。(CVE-2022-32221)
- 当 curl 用于检索和解析来自 HTTP(S) 服务器的 cookie 时，它使用控制代码接受 cookie，这些代码稍后被发送回 HTTP 服务器时可能会使服务器返回 400 响应。
有效地令辅助站点拒绝向所有同级站点提供服务。(CVE-2022-35252)
- 低于 7.84.0 版的 curl 在执行受 krb5 保护的 FTP 传输时，会错误处理消息验证失败。
攻击者可利用此缺陷执行中间人攻击而不被发现，甚至可以向客户端注入数据。(CVE-2022-32208)
- 低于 7.84.0 版的 curl 将 cookie、alt-svc 和 hsts 数据保存到本地文件时，会通过将临时名称重命名为最终目标文件名称来完成操作，从而使该操作成为原子型操作。在该重命名操作中，它可能会意外*放宽*对目标文件的权限，使更多用户可访问更新后的文件。(CVE-2022-32207)
- curl 7.84.0 以下版本支持链接的 HTTP 压缩算法，这意味着服务器响应可被多次压缩，并且可能使用不同的算法。此解压缩链中可接受的链接数量不受限制，因此恶意服务器可以插入数量几乎无限制的压缩步骤。使用此类解压缩链可能导致 malloc 炸弹，使 curl 最终消耗大量分配的堆内存，或尝试并返回内存不足错误。(CVE-2022-32206)
- 恶意服务器可以在对 curl 的 HTTP 响应中提供过量的“Set-Cookie:”标头，而 curl 7.84.0 之前的版本会存储所有这些标头。数量够多（大）的 cookie 会向此服务器或这些 cookie 相匹配的其他服务器发出后续 HTTP 请求，从而使创建的请求超过 curl 为避免发送过大请求（1048576 字节）而在内部使用的阈值，而没有返回错误。只要保留和匹配这些 cookie 并且它们未过期，此拒绝状态就可能持续存在。由于 cookie 匹配规则，“foo.example.com”上的服务器可以设置匹配“bar.example.com”的 cookie，从而使同级服务器可以有效造成相同二级域上使用此方法的同级网站拒绝服务。(CVE-2022-32205)
- 使用其 HSTS 支持，即使在 URL 中提供 HTTP 时，也可指示 curl 直接使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。如果给定 URL 中的主机名使用了结尾点而未使用构建 HSTS 缓存时的结尾点，则可绕过此机制。或者反过来
- 在 HSTS 缓存中使用结尾点，而*不在* URL 中使用结尾点。
(CVE-2022-30115)
- 即便已更改 TLS 或 SSH 相关选项，libcurl 仍会重复使用以前创建的连接，而这些连接本应禁止重复使用。如果其中一个连接与设置匹配，libcurl 会将以前用过的连接保留在连接池中，以便后续传输重复使用。但是，配置匹配检查会遗漏多个 TLS 和 SSH 设置，使匹配变得过于容易。(CVE-2022-27782)
- libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时被卡在忙碌等待的死循环中。
(CVE-2022-27781)
- 解码 URL 的主机名部分时，curl URL 解析器会错误接受诸如“/”的以百分号编码的 URL 分隔符，从而使其在以后检索时成为使用错误主机名的*不同* URL。例如，解析器会允许诸如 `http://example.com%2F127.0.0.1/` 的 URL 并将其转置为 `http://example.com/127.0.0.1/`。攻击者可利用此缺陷避开筛选和检查等。
(CVE-2022-27780)
- 如果主机名以一个点结尾，libcurl 会错误允许为顶级域 (TLD) 设置 cookie。可指示 curl 接收和发送 cookie。在构建 curl 的 cookie 引擎时，可以使用 [公共后缀列表]，也可以不使用 (https://publicsuffix.org/)awareness。如果不提供 PSL 支持，则需要初步检查，以至少防止在 TLD 上设置 cookie。如果 URL 中的主机名以一个点结尾，此检查会被中断。这可允许任意站点设置 cookie，然后将其发送至不同且不相关的站点或域。(CVE-2022-27779)
- 当“--no-clobber”与“--remove-on-error”一起使用时，7.83.1 版中已修复的使用错误解析的名称漏洞可能会删除错误的文件。(CVE-2022-27778)
- curl 7.83.0 版中修复的凭据保护不充分漏洞可能会在 HTTP 重定向到相同主机不同端口号时泄漏身份验证或 Cookie 标头数据。(CVE-2022-27776)
- curl 7.65.0 至 7.82.0 中存在信息泄露漏洞，在使用连接池中具有不同区域 ID 的 IPv6 地址时，它可能会重复使用连接。(CVE-2022-27775)
- curl 4.9 至 7.82.0 版（含）存在凭据保护不充分漏洞，允许攻击者在遵循身份验证中结合使用的 HTTP(S) 重定向时提取凭据，将凭据泄露给不同协议或端口号上的其他服务。
(CVE-2022-27774)
- curl 7.33.0 至 7.82.0（含）版本中存在一个不当认证漏洞，从而可能允许在未正确确保已使用为传输设置的相同凭据来认证连接的情况下，重复使用经 OAUTH2 认证的连接。这会影响启用 SASL 的协议：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S)（仅限 openldap）。(CVE-2022-22576)
- 当 7.20.0、7.78.0 及其之间的 curl 版本连接到 IMAP 或 POP3 服务器以使用 STARTTLS 检索数据进而升级到 TLS 安全时，服务器可以响应并立即发回 curl 缓存的多个响应。
然后，curl 会升级至 TLS，但不会刷新缓存响应的队列，而是继续使用和信任其在 TLS 握手*之前*获得的响应，就好像这些响应已经过身份验证一样。中间人攻击者可使用此缺陷，首先注入虚假响应，然后传递来自合法服务器的 TLS 流量，并诱使 curl 认为攻击者注入的数据来自受 TLS 保护的服务器，从而向用户发回数据。(CVE-2021-22947)
- 用户可以在与 IMAP、POP3 或 FTP 服务器通信时，告知 7.20.0、7.78.0 及其之间的 curl 版本需要成功升级至 TLS（命令行的 `--ssl-reqd` 或`CURLOPT_USE_SSL` 设置为带有 libcurl 的 `CURLUSESSL_CONTROL` 或 `CURLUSESSL_ALL`）。如果服务器返回构建正确且完全合法的响应，则可绕过此要求。此缺陷将使 curl 默默地继续其操作
**无 TLS** 违反说明和预期，可通过网络以明文形式暴露可能的敏感数据。(CVE-2021-22946)
- 向 MQTT 服务器发送数据时，libcurl <= 7.73.0 和 7.78.0 版在某些情况下可能会错误地保留指向已释放内存区域的指针，并在后续调用中再次使用该指针来发送数据，并*再次* 释放。(CVE-2021-22945)
- libcurl-using 应用程序可要求在传输中使用特定的客户端证书。这一要求可通过 `CURLOPT_SSLCERT` 选项（命令行工具的 `--cert`）完成。当 libcurl 被构建为使用 macOS 本机 TLS 库安全传输时，应用程序可通过相同的选项，按名称或文件名请求客户端证书。如果名称以文件形式存在，则将使用文件而非名称。如果应用程序在可由其他用户写入的当前工作目录（如“/tmp”）下运行，恶意用户可使用与应用程序要使用的名称相同的名称，从而诱骗应用程序使用基于文件的证书，而不是名称引用的证书，从而使 libcurl 在 TLS 连接握手中发送错误的客户端证书。(CVE-2021-22926)
- curl 支持“-t”命令行选项，在 libcurl 中称为“CURLOPT_TELNETOPTIONS”。这个极少使用的选项用于将 variable=content 对发送到 TELNET 服务器。由于用于发送“NEW_ENV”变量的选项解析器中存在一个缺陷，可以让 libcurl 将未初始化的数据从基于堆栈的缓冲区传递到服务器。因此，可能会使用明文网络协议向服务器显示敏感的内部信息。发生这种情况的原因是 curl 在解析应用程序提供的字符串时未正确调用和使用 sscanf()。(CVE-2021-22925)
- LibCurl 将先前使用的连接保留在连接池中，以供后续传输重新使用（如果其中一个连接与设置匹配）。由于逻辑错误，配置匹配函数没有考虑“发行者证书”，且比较了涉及路径中的*不区分大小写*，这可导致 LibCurl 重新使用错误的连接。文件路径在许多系统中会（或可能）区分大小写，但不是全部，并且甚至会因使用的文件系统而不同。比较中未包括“发行者证书”，传输可对其进行设置，以限制验证服务器的方式。 (CVE-2021-22924)
- 当 curl 收到使用 metalink 功能获取内容的指示时，并使用用户名和密码下载 metalink XML 文件时，这些相同凭据随后会被传递到 curl 将从其下载或尝试下载内容的每个服务器。通常违背用户的预期和意图，并且未将发生的情况告知用户。(CVE-2021-22923)
- 当 curl 收到使用 metalink 功能下载内容的指示时，将根据 metalink XML 文件中提供的哈希验证内容。metalink XML 文件向客户端指出如何从一组不同的 URL 获取相同的内容（可能由不同的服务器托管），随后客户端便可从一个或多个 URL 下载该文件。以串行或并行方式。如果托管内容的某个服务器遭到破坏，且该服务器上特定文件的内容被修改后的负载替换，则在下载完成后，curl 会在文件的哈希值不匹配时检测到这一点。
客户端应该删除这些内容，并尝试从另一个 URL 获取内容。此操作未完成，而是仅在文本中提及此类哈希不匹配，并且可能的恶意内容将被保留在磁盘上的文件中。(CVE-2021-22922)
- curl 7.75.0 至 7.76.1 受到释放后使用漏洞的影响，导致 1.3 TLS 会话票证通过连接到达时使用已释放的内存。在极少数不够幸运的情况下，恶意服务器可利用此漏洞，在客户端造成远程代码执行。当 libcurl 在运行时对使用 OpenSSL 的连接设置对 TLS 1.3 会话票证的支持时，会存储指向传输内存对象的指针，以便稍后在会话票证到达时进行检索。如果多个传输使用了该连接（例如通过重用的 HTTP/1.1 连接或多路复用 HTTP/2 连接），则在该连接上建立新会话之前，第一个传输对象可能会被释放，然后该函数将访问可能被释放的内存缓冲区。使用该内存时，libcurl 甚至可能调用对象中的函数指针，如果服务器能够以某种方式将构建的内存内容放入内存中的正确位置，则可能执行远程代码。(CVE-2021-22901)
- 当“-t”命令行选项（在 libcurl 中称为“CURLOPT_TELNETOPTIONS”）用于将 variable=content 对发送到 TELNET 服务器时，curl 7.7 到 7.76.1 受到信息泄露漏洞的影响。用于发送 NEW_ENV 变量的选项解析器中存在一个缺陷，因此 libcurl 可能会被用于将未初始化的数据从基于堆栈的缓冲区传递到服务器，从而可能导致使用明文网络协议将敏感的内部信息泄露给服务器。(CVE-2021-22898)
- 当 libcurl 被构建为使用 Schannel TLS 库时，由于 CURLOPT_SSL_CIPHER_LIST 的代码中存在错误，curl 7.61.0 到 7.76.1 受到暴露于错误会话的影响。所选密码集存储在库中的单个静态变量中，其具有令人意外的副作用，即如果应用程序设置了多个并发传输，则设置密码的最后一个传输将意外控制所有传输使用的密码集。在最坏的情况下，这会大大削弱传输安全性。(CVE-2021-22897)
- curl 7.63.0 至 7.75.0（含）版存在漏洞，由于应用程序未正确处理 TLS 1.3 会话票证，恶意 HTTPS 代理可对连接执行 MITM 攻击。使用 HTTPS 代理和 TLS 1.3 时，libcurl 可能会混淆从 HTTPS 代理收到的会话票证，并在运行时将其视同从远程服务器收到的票证，然后错误地以快捷方式与主机握手。当混淆票证时，HTTPS 代理可诱骗 libcurl 使用主机的错误会话票证恢复，从而规避服务器 TLS 证书检查，使攻击者有可能执行 MITM 攻击而不被发现。 请注意，此类恶意 HTTPS 代理需要为充当中间人的服务器提供 curl 接受的证书才能执行攻击，除非 curl 被告知忽略服务器证书检查。(CVE-2021-22890)
- curl 7.1.1 至 7.75.0 版（包括后者）容易受到通过泄漏 HTTP Referer: 标头中的凭据向未经授权的攻击者暴露隐私个人信息的影响。在出站 HTTP 请求中自动填充 Referer: HTTP 请求标头字段时，libcurl 不会从 URL 中剥离用户凭据，因此有可能将敏感数据泄漏给第二个 HTTP 请求的目标服务器。(CVE-2021-22876)
- curl 7.41.0 到 7.73.0 容易受到证书吊销检查不当的影响，这是未充分验证 OCSP 响应所致。(CVE-2020-8286)
- curl 7.21.0 到 7.73.0（包含）的版本容易受到非受控递归的攻击，这是 FTP 通配符匹配解析中的堆栈溢出问题所致。(CVE-2020-8285)
- 恶意服务器可使用 FTP PASV 响应诱骗 curl 7.73.0 及更早版本连接回给定的 IP 地址和端口，而这种方式可能会让 curl 提取有关非公开且不应披露的服务的信息，例如进行端口操作扫描和服务标题提取。
(CVE-2020-8284)
- 由于使用悬垂指针，libcurl 7.29.0 到 7.71.1 的版本会在发送数据时使用错误的连接。(CVE-2020-8231)
- curl 7.20.0 - 7.70.0 容易受到未正确限制文件和其他资源名称的影响，在使用 -J 标记时，此漏洞可导致覆盖本地文件。(CVE-2020-8177)
- curl 7.62.0 到 7.70.0 版容易受到信息泄露漏洞的影响，可导致通过网络将部分密码泄漏给 DNS 服务器。(CVE-2020-8169)
- 在 3.6.2 版之前的 libarchive 中，软件在调用 calloc 函数后不会检查错误，如果函数失败，可返回空指针，从而导致空指针取消引用。
注意：发现者引用了此 CWE-476 评论，但第三方对代码执行的影响存在争议：在极少数情况下，当 NULL 等同于 0x0 内存地址且特权代码可以访问它时，可以写入或读取内存，这可能导致代码执行。(CVE-2022-36227)
- 提取存档时可能发生不正确的链接解析缺陷，从而导致存档外文件的模式、时间、访问控制列表和标记发生更改。攻击者可能向受害用户提供恶意存档，受害者会在尝试提取存档时触发此缺陷。本地攻击者可能利用此缺陷在系统中获得更多权限。(CVE-2021-31566)
- libarchive 3.4.1 版至 3.5.1 版的 copy_string（从 do_uncompress_block 和 process_block 调用）中存在释放后使用漏洞。(CVE-2021-36976)
- lz4 中存在一个缺陷。向与 lz4 链接的应用程序提交构建文件的攻击者可能能够触发整数溢出，进而导致对负大小参数调用 memmove()，从而导致越界写入和/或崩溃。此缺陷对可用性影响最大，对机密性和完整性也可能产生一定影响。(CVE-2021-3520)
- 低于 8.44 的 PCRE 中的 libpcre 可通过 (?C 子字符串之后的大数，造成整数溢出。
(CVE-2020-14155)
- 当模式 \X 经过 JIT 编译并用于匹配非 UTF 模式中特别构建的主题时，在 10.34 之前的 PCRE 中发现越界读取。使用 PCRE 解析不受信任输入的应用程序可能容易受到此缺陷攻击，这允许攻击者造成应用程序崩溃。该缺陷会在 pcre2_jit_compile.c 的 do_extuni_no_utf 中出现。(CVE-2019-20454)
- 当禁用 UTF 且 \X 或 \R 具有多个固定的限定符时，低于 8.43 的 PCRE 中的 libpcre 可导致 JIT 中发生主题缓冲区过度读取，此问题与 CVE-2019-20454 相关。(CVE-2019-20838)
- 如果在 C API 的字符串参数中使用了数十亿字节，则在 3.39.2 之前的 SQLite 1.0.12 至 3.39.x 有时允许数组边界溢出。(CVE-2022-35737)
请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。
解决方案
对于 Splunk Universal Forwarder，请升级到 8.2.12、9.0.6 或 9.1.1。另见
插件详情
严重性: Critical
ID: 194926
文件名: splunk_911_svd-2023-0809.nasl
版本: 1.2
类型: combined
代理: windows, macosx, unix
系列: CGI abuses
发布时间: 2024/5/2
最近更新时间: 2024/5/30
支持的传感器: Nessus Agent, Nessus
风险信息
VPR
风险因素: Medium
分数: 6.7
CVSS v2
风险因素: High
基本分数: 7.5
时间分数: 5.9
矢量: CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P
CVSS 分数来源: CVE-2022-32207
CVSS v3
风险因素: Critical
基本分数: 9.8
时间分数: 8.8
矢量: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
时间矢量: CVSS:3.0/E:P/RL:O/RC:C
CVSS 分数来源: CVE-2022-36227
漏洞信息
CPE: cpe:/a:splunk:universal_forwarder, cpe:/a:splunk:splunk
可利用: true
易利用性: Exploits are available
补丁发布日期: 2023/8/30
漏洞发布日期: 2023/8/30
参考资料信息
CVE: CVE-2019-20454, CVE-2019-20838, CVE-2020-14155, CVE-2020-8169, CVE-2020-8177, CVE-2020-8231, CVE-2020-8284, CVE-2020-8285, CVE-2020-8286, CVE-2021-22876, CVE-2021-22890, CVE-2021-22897, CVE-2021-22898, CVE-2021-22901, CVE-2021-22922, CVE-2021-22923, CVE-2021-22924, CVE-2021-22925, CVE-2021-22926, CVE-2021-22945, CVE-2021-22946, CVE-2021-22947, CVE-2021-30560, CVE-2021-31566, CVE-2021-3520, CVE-2021-36976, CVE-2022-22576, CVE-2022-27774, CVE-2022-27775, CVE-2022-27776, CVE-2022-27778, CVE-2022-27779, CVE-2022-27780, CVE-2022-27781, CVE-2022-27782, CVE-2022-30115, CVE-2022-32205, CVE-2022-32206, CVE-2022-32207, CVE-2022-32208, CVE-2022-32221, CVE-2022-35252, CVE-2022-35260, CVE-2022-35737, CVE-2022-36227, CVE-2022-42915, CVE-2022-42916, CVE-2022-43551, CVE-2022-43552, CVE-2023-23914, CVE-2023-23915, CVE-2023-23916, CVE-2023-27533, CVE-2023-27534, CVE-2023-27535, CVE-2023-27536, CVE-2023-27537, CVE-2023-27538