GLSA-202212-01 : curl：多个漏洞

critical Nessus 插件 ID 168911

语言：

描述

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

- 当 curl 收到使用 metalink 功能下载内容的指示时，将根据 metalink XML 文件中提供的哈希验证内容。metalink XML 文件向客户端指出如何从一组不同的 URL 获取相同的内容（可能由不同的服务器托管），随后客户端便可从一个或多个 URL 下载该文件。以串行或并行方式。如果托管内容的某个服务器遭到破坏，且该服务器上特定文件的内容被修改后的负载替换，则在下载完成后，curl 会在文件的哈希值不匹配时检测到这一点。
客户端应该删除这些内容，并尝试从另一个 URL 获取内容。此操作未完成，而是仅在文本中提及此类哈希不匹配，并且可能的恶意内容将被保留在磁盘上的文件中。(CVE-2021-22922)

- 当 curl 收到使用 metalink 功能获取内容的指示时，并使用用户名和密码下载 metalink XML 文件时，这些相同凭据随后会被传递到 curl 将从其下载或尝试下载内容的每个服务器。通常违背用户的预期和意图，并且未将发生的情况告知用户。(CVE-2021-22923)

- curl 支持“-t”命令行选项，在 libcurl 中称为“CURLOPT_TELNETOPTIONS”。这个极少使用的选项用于将 variable=content 对发送到 TELNET 服务器。由于用于发送“NEW_ENV”变量的选项解析器中存在一个缺陷，可以让 libcurl 将未初始化的数据从基于堆栈的缓冲区传递到服务器。因此，可能会使用明文网络协议向服务器显示敏感的内部信息。发生这种情况的原因是 curl 在解析应用程序提供的字符串时未正确调用和使用 sscanf()。(CVE-2021-22925)

- libcurl-using 应用程序可要求在传输中使用特定的客户端证书。这一要求可通过 `CURLOPT_SSLCERT` 选项（命令行工具的 `--cert`）完成。当 libcurl 被构建为使用 macOS 本机 TLS 库安全传输时，应用程序可通过相同的选项，按名称或文件名请求客户端证书。如果名称以文件形式存在，则将使用文件而非名称。如果应用程序在可由其他用户写入的当前工作目录（如“/tmp”）下运行，恶意用户可使用与应用程序要使用的名称相同的名称，从而诱骗应用程序使用基于文件的证书，而不是名称引用的证书，从而使 libcurl 在 TLS 连接握手中发送错误的客户端证书。(CVE-2021-22926)

- 向 MQTT 服务器发送数据时，libcurl <= 7.73.0 和 7.78.0 版在某些情况下可能会错误地保留指向已释放内存区域的指针，并在后续调用中再次使用该指针来发送数据，并*再次* 释放。(CVE-2021-22945)

- 用户可以在与 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)

- 当 7.20.0、7.78.0 及其之间的 curl 版本连接到 IMAP 或 POP3 服务器以使用 STARTTLS 检索数据进而升级到 TLS 安全时，服务器可以响应并立即发回 curl 缓存的多个响应。
然后，curl 会升级至 TLS，但不会刷新缓存响应的队列，而是继续使用和信任其在 TLS 握手*之前*获得的响应，就好像这些响应已经过身份验证一样。中间人攻击者可使用此缺陷，首先注入虚假响应，然后传递来自合法服务器的 TLS 流量，并诱使 curl 认为攻击者注入的数据来自受 TLS 保护的服务器，从而向用户发回数据。(CVE-2021-22947)

- curl 7.33.0 至 7.82.0（含）版本中存在一个不当认证漏洞，从而可能允许在未正确确保已使用为传输设置的相同凭据来认证连接的情况下，重复使用经 OAUTH2 认证的连接。此漏洞会影响启用了 SASL 的协议：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S)（仅限 openldap）。(CVE-2022-22576)

- curl 4.9 至 7.82.0 版（含）存在凭据保护不充分漏洞，允许攻击者在遵循身份验证中结合使用的 HTTP(S) 重定向时提取凭据，将凭据泄露给不同协议或端口号上的其他服务。
(CVE-2022-27774)

- curl 7.65.0 至 7.82.0 中存在信息泄露漏洞，在使用连接池中具有不同区域 ID 的 IPv6 地址时，它可能会重复使用连接。(CVE-2022-27775)

- curl 7.83.0 版中修复的凭据保护不充分漏洞可能会在 HTTP 重定向到相同主机不同端口号时泄漏身份验证或 Cookie 标头数据。(CVE-2022-27776)

- 如果主机名以一个点结尾，libcurl 会错误允许为顶级域 (TLD) 设置 cookie。可指示 curl 接收和发送 cookie。在构建 curl 的 cookie 引擎时，可以使用 [公共后缀列表]，也可以不使用 (https://publicsuffix.org/)awareness。如果不提供 PSL 支持，则需要初步检查，以至少防止在 TLD 上设置 cookie。如果 URL 中的主机名以一个点结尾，此检查会被中断。这可允许任意站点设置 cookie，然后将其发送至不同且不相关的站点或域。(CVE-2022-27779)

- 解码 URL 的主机名部分时，curl URL 解析器会错误接受诸如“/”的以百分号编码的 URL 分隔符，从而使其在以后检索时成为使用错误主机名的*不同* URL。例如，解析器会允许诸如 `http://example.com%2F127.0.0.1/` 的 URL 并将其转置为 `http://example.com/127.0.0.1/`。攻击者可利用此缺陷避开筛选和检查等。
(CVE-2022-27780)

- libcurl 提供“CURLOPT_CERTINFO”选项，以允许应用程序请求返回有关服务器证书链的详细信息。由于使用错误函数，恶意服务器可造成使用 NSS 构建的 libcurl 在尝试检索此信息时被卡在忙碌等待的死循环中。
(CVE-2022-27781)

- 即便已更改 TLS 或 SSH 相关选项，libcurl 仍会重复使用以前创建的连接，而这些连接本应禁止重复使用。如果其中一个连接与设置匹配，libcurl 会将以前用过的连接保留在连接池中，以便后续传输重复使用。但是，配置匹配检查会遗漏多个 TLS 和 SSH 设置，使匹配变得过于容易。(CVE-2022-27782)

- 使用其 HSTS 支持，即使在 URL 中提供 HTTP 时，也可指示 curl 直接使用 HTTPS，而不是使用不安全的明文 HTTP 步骤。如果给定 URL 中的主机名使用了结尾点而未使用构建 HSTS 缓存时的结尾点，则可绕过此机制。或者反过来
- 在 HSTS 缓存中使用结尾点，而*不在* URL 中使用结尾点。
(CVE-2022-30115)

- 恶意服务器可在 HTTP 响应中提供过量的 `Set-Cookie:` 标头，而低于 7.84.0 版的 curl 会存储所有这些标头。数量够多（大）的 cookie 会向此服务器或这些 cookie 相匹配的其他服务器发出后续 HTTP 请求，从而使创建的请求超过 curl 为避免发送过大请求（1048576 字节）而在内部使用的阈值，而没有返回错误。只要保留和匹配这些 cookie 并且它们未过期，此拒绝状态就可能持续存在。由于 cookie 匹配规则，“foo.example.com”上的服务器可以设置匹配“bar.example.com”的 cookie，从而使同级服务器可以有效造成相同二级域上使用此方法的同级网站拒绝服务。(CVE-2022-32205)

- curl 7.84.0 以下版本支持链接的 HTTP 压缩算法，这意味着服务器响应可被多次压缩，并且可能使用不同的算法。此解压缩链中可接受的链接数量不受限制，因此恶意服务器可以插入数量几乎无限制的压缩步骤。使用此类解压缩链可能导致 malloc 炸弹，使 curl 最终消耗大量分配的堆内存，或尝试并返回内存不足错误。(CVE-2022-32206)

- 低于 7.84.0 版的 curl 将 cookie、alt-svc 和 hsts 数据保存到本地文件时，会通过将临时名称重命名为最终目标文件名称来完成操作，从而使该操作成为原子型操作。在该重命名操作中，它可能会意外*放宽*对目标文件的权限，使更多用户可访问更新后的文件。(CVE-2022-32207)

- 低于 7.84.0 版的 curl 在执行受 krb5 保护的 FTP 传输时，会错误处理消息验证失败。
攻击者可利用此缺陷执行中间人攻击而不被发现，甚至可以向客户端注入数据。(CVE-2022-32208)

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

- 当 curl 用于检索和解析来自 HTTP(S) 服务器的 cookie 时，它使用控制代码接受 cookie，这些代码稍后被发送回 HTTP 服务器时可能会使服务器返回 400 响应。
有效地令辅助站点拒绝向所有同级站点提供服务。(CVE-2022-35252)

- 可指示 curl 解析 `.netrc` 文件以获取凭据。如果该文件以具有 4095 个连续非空白字符且无换行符的行结尾，则 curl 将首先读取超过基于堆栈的缓冲区的末尾，如果是 readworks，则写入一个超出其边界的零字节。在大多数情况下此问题会造成段错误或类似问题，但不同的环境也可能造成不同的结果。如果恶意用户可以向应用程序提供自定义 netrc 文件，或以其他方式影响其内容，则此缺陷可被用作拒绝服务。(CVE-2022-35260)

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

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

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