GLSA-202310-12 : curl：多个漏洞

critical Nessus 插件 ID 182879

语言：

描述

远程主机受到 GLSA-202310-12 中所述漏洞的影响（curl：多个漏洞）

- 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)

- curl <7.87.0 中存在释放后使用漏洞。可要求 Curl 通过 HTTP 代理*传输*其支持的几乎所有协议。HTTP 代理可以（而且经常会）拒绝此类传输操作。
如果传输特定协议 SMB 或 TELNET 被拒，Curl 会在其传输关闭代码路径中使用已释放的堆分配结构。(CVE-2022-43552)

- curl <v7.88.0 中存在敏感信息明文传输漏洞，当连续请求多个 URL 时，可能导致 HSTS 功能失败。如使用 HSTS 支持，即使在 URL 中提供了 HTTP，仍可指示 curl 使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。然而，令人意外的是，当在相同命令行上完成时，此 HSTS 机制会被后续传输忽略，因为状态不会正确维持下去。 (CVE-2023-23914)

- curl <v7.88.0 中存在敏感信息明文传输漏洞，当同时请求多个 URL 时，可能导致 HSTS 功能表现不当。如使用 HSTS 支持，即使在 URL 中提供了 HTTP，仍可指示 curl 使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。然而，当并行完成多个传输时，此 HSTS 机制会出人意料地失败，因为 HSTS 缓存文件被最近完成的传输覆盖。之后向之前主机名的仅 HTTP 传输将*不会*正确升级到 HSTS。
(CVE-2023-23915)

- 在基于链接的 HTTP 压缩算法且版本低于 v7.88.0 的 curl 中存在配置资源时无限制或节流的漏洞，这意味着服务器响应可被多次压缩，并且可能使用不同的算法。已针对此解压缩链中可接受的链接数量设置上限，但该上限基于每个标题设置，所以恶意服务器仅使用许多标头即可插入几乎无数量上限的压缩步骤。使用此类解压缩链可导致 malloc 炸弹，使 curl 最终消耗大量分配的堆内存，或尝试并返回内存不足错误。(CVE-2023-23916)

- 使用 TELNET 协议进行通信期间，低于 8.0 版的 curl 的输入验证存在漏洞，可能允许攻击者在服务器协商期间传递恶意构建的用户名和 telnet 选项。
缺少正确的输入以清理允许攻击者在没有应用程序意图的情况下发送内容或执行选项协商。如果应用程序允许用户输入，则攻击者可利用此漏洞，进而能够在系统上执行任意代码。(CVE-2023-27533)

- 在低于 8.0.0 版的 curl 的 SFTP 实现中存在一个路径遍历漏洞，除波浪号 (~) 字符预期用作第一个元素以指示相对于用户主目录的路径外，该漏洞会导致波浪号 (~) 字符在第一个路径元素中用作前缀时被错误替换。攻击者可在使用特定用户访问服务器时，通过构建类似 /~2/foo 的路径，利用此缺陷绕过过滤或执行任意代码。(CVE-2023-27534)

- 在低于 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 版的 libcurl 的连接重用功能中存在认证绕过漏洞，由于未能检查 CURLOPT_GSSAPI_DELEGATION 选项中的更改，该漏洞可重用之前建立的连接。此漏洞会影响 krb5/kerberos/negotiate/GSSAPI 传输，并可能导致对敏感信息进行未经授权的访问。最安全的做法是在 CURLOPT_GSSAPI_DELEGATION 选项已更改时不重复使用连接。(CVE-2023-27536)

- 在低于 8.0.0 版的 libcurl 中，若在单独的句柄之间共享 HSTS 数据，则会出现双重释放漏洞。
引入此共享时未考虑在单独的线程之间执行此共享，但文档未对此情况进行说明。由于缺少互斥体或线程锁，共享相同 HSTS 数据的两个线程可能以执行双重释放或释放后使用而告终。(CVE-2023-27537)

- 在低于 v8.0.0 版的 libcurl 中存在身份验证绕过漏洞，尽管修改了 SSH 选项，但该漏洞仍会重用之前建立的 SSH 连接，而不是阻止重用。libcurl 维护一个之前使用过的连接池，以在配置匹配时将其重新用于后续传输。但是，配置检查中忽略了两个 SSH 设置，从而使这两个设置可以轻松匹配，进而可能导致重复使用不适当的连接。(CVE-2023-27538)

- 低于 v8.1.0 的 curl 中存在一个释放后使用漏洞，libcurl 借此提供了使用 SHA 256 哈希验证 SSH 服务器公钥的功能。若此检查失败，libcurl 会先释放指纹内存，然后再返回含有（现已释放）哈希的错误消息。此缺陷存在将基于堆的敏感数据插入本可能向用户显示或以其他方式泄露和显示的错误消息的风险。(CVE-2023-28319)

- 低于 v8.1.0 的 curl 中存在一个拒绝服务漏洞，libcurl 提供了几种不同的后端来解析主机名，以供在构建时选择。如果构建为使用同步解析器，则会允许名称解析使用“alarm()”和“siglongjmp()”暂停缓慢的操作。执行此操作时，libcurl 使用了不受互斥体保护的全局缓冲区，多线程的应用程序可能因此崩溃或出现其他错误行为。(CVE-2023-28320)

- curl v8.1.0 之前版本中存在证书验证不当漏洞。它会支持比对 TLS 服务器证书中作为主题备用名称列出的通配符模式。curl 可以被建构为针对 TLS 使用其自己的名称匹配函数，而不是 TLS 库的函数。此私密通配符匹配函数会错误匹配 IDN（国际域名）主机，并因此接受本应不匹配的模式。IDN 主机名在用于证书检查之前会被转换为域名代码。Puny 编码名称总是以“xn--”开头，且不应允许进行模式匹配，但 curl 中的通配符检查仍可检查“x*”，即使 IDN 名称很可能不包含任何类似“x”的符号亦然。(CVE-2023-28321)

- curl v8.1.0 之前版本中存在信息泄露漏洞。在进行 HTTP(S) 传输时，如果之前使用相同的句柄发出 `PUT` 请求（使用读取回调 (`CURLOPT_READFUNCTION`)），即使设置了 `CURLOPT_POSTFIELDS` 选项，libcurl 仍可能会错误地使用该回调来请求发送数据。此缺陷可能会使应用程序发生意外并导致其行为不当，在第二次传输中发送错误的数据，或使用释放后的内存或类似内容。从 PUT 更改为 POST 时（此为预期行为），重用句柄的逻辑中存在此问题。(CVE-2023-28322)

- 当 curl 检索 HTTP 响应时，即会存储传入的标头，以便稍后可以通过 libcurl 标头 API 访问它们。然而，curl 在响应中接受的标头数量或大小并无限制，从而允许恶意服务器流式传输一连串无尽的标头，并最终导致 curl 耗尽堆内存。(CVE-2023-38039)

- CVE-2023-38545 是 libcurl 和 curl 的 SOCKS5 代理握手中存在的基于堆的缓冲区溢出漏洞。当为 curl 提供一个主机名以传递给长度大于 255 字节的 SOCKS5 代理时，它将切换到本地名称解析，以便在将其传递给 SOCKS5 代理之前解析该地址。但由于 2020 年引入的错误，此本地名称解析可能会因 SOCKS5 握手缓慢而失败，导致 curl 将长度大于 255 字节的主机名传递到目标缓冲区，从而导致堆溢出情形。 CVE-2023-38545 的公告中提供了重定向到特制 URL 的恶意 HTTPS 服务器的示例利用情况。虽然攻击者似乎需要影响 SOCKS5 握手的缓慢程度，但该公告指出，服务器延迟可能足够缓慢，足以触发此错误。(CVE-2023-38545)

- 如需详细信息，请查看供参考的 CVE 标识符。请注意，远程代码执行的风险仅限于 SOCKS 的使用。(CVE-2023-38546)

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