FreshPorts - VuXML

selmelc on hackerone reports:

When curl retrieves an HTTP response, it stores the incoming headers so that they can be accessed later via the libcurl headers API.

However, curl did not have a limit in how many or how large headers it would accept in a response, allowing a malicious server to stream an endless series of headers and eventually cause curl to run out of heap memory.

< 8.3.0

The cURL project reports:

• UAF and double-free in MQTT sending (CVE-2021-22945)
• Protocol downgrade required TLS bypassed (CVE-2021-22946)
• STARTTLS protocol injection via MITM (CVE-2021-22945)

ge 7.20.0 lt 7.79.0

Daniel Stenberg reports:

Enabled by default, libcurl supports the use of TLS 1.3 session tickets to resume previous TLS sessions to speed up subsequent TLS handshakes.

When using a HTTPS proxy and TLS 1.3, libcurl can confuse session tickets arriving from the HTTPS proxy but work as if they arrived from the remote server and then wrongly "short-cut" the host handshake. The reason for this confusion is the modified sequence from TLS 1.2 when the session ids would provided only during the TLS handshake, while in TLS 1.3 it happens post hand-shake and the code was not updated to take that changed behavior into account.

When confusing the tickets, a HTTPS proxy can trick libcurl to use the wrong session ticket resume for the host and thereby circumvent the server TLS certificate check and make a MITM attack to be possible to perform unnoticed.

This flaw can allow a malicious HTTPS proxy to MITM the traffic. Such a malicious HTTPS proxy needs to provide a certificate that curl will accept for the MITMed server for an attack to work - unless curl has been told to ignore the server certificate check.

ge 7.63.0 lt 7.76.0

Daniel Stenberg reports:

CVE-2022-32221: POST following PUT confusion

When doing HTTP(S) transfers, libcurl might erroneously use the read callback (CURLOPT_READFUNCTION) to ask for data to send, even when the CURLOPT_POSTFIELDS option has been set, if the same handle previously was used to issue a PUT request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the subsequent POST request. The problem exists in the logic for a reused handle when it is changed from a PUT to a POST.

CVE-2022-35260: .netrc parser out-of-bounds access

curl can be told to parse a .netrc file for credentials. If that file ends in a line with consecutive non-white space letters and no newline, curl could read past the end of the stack-based buffer, and if the read works, write a zero byte possibly beyond its boundary. This will in most cases cause a segfault or similar, but circumstances might also cause different outcomes. If a malicious user can provide a custom netrc file to an application or otherwise affect its contents, this flaw could be used as denial-of-service.

CVE-2022-42915: HTTP proxy double-free

f curl is told to use an HTTP proxy for a transfer with a non-HTTP(S) URL, it sets up the connection to the remote server by issuing a CONNECT request to the proxy, and then tunnels the rest of protocol through. An HTTP proxy might refuse this request (HTTP proxies often only allow outgoing connections to specific port numbers, like 443 for HTTPS) and instead return a non-200 response code to the client. Due to flaws in the error/cleanup handling, this could trigger a double-free in curl if one of the following schemes were used in the URL for the transfer: dict, gopher, gophers, ldap, ldaps, rtmp, rtmps, telnet

CVE-2022-42916: HSTS bypass via IDN

curl's HSTS check could be bypassed to trick it to keep using HTTP. Using its HSTS support, curl can be instructed to use HTTPS directly instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. This mechanism could be bypassed if the host name in the given URL uses IDN characters that get replaced to ASCII counterparts as part of the IDN conversion. Like using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop (U+002E) .. Like this: http://curl。se。

< 7.86.0

Daniel Stenberg reports:

libcurl does not strip off user credentials from the URL when automatically populating the Referer: HTTP request header field in outgoing HTTP requests, and therefore risks leaking sensitive data to the server that is the target of the second HTTP request.

libcurl automatically sets the Referer: HTTP request header field in outgoing HTTP requests if the CURLOPT_AUTOREFERER option is set. With the curl tool, it is enabled with --referer ";auto".

ge 7.1.1 lt 7.76.0

The cURL project reports:

Trusting FTP PASV responses (CVE-2020-8284)

FTP wildcard stack overflow (CVE-2020-8285)

Inferior OCSP verification (CVE-2020-8286)

gt 4.0 lt 7.74.0

Hiroki Kurosawa reports:

curl inadvertently kept the SSL session ID for connections in its cache even when the verify status (OCSP stapling) test failed. A subsequent transfer to the same hostname could then succeed if the session ID cache was still fresh, which then skipped the verify status check.

< 8.6.0

The curl project reports:

CVE-2022-27778: curl removes wrong file on error

CVE-2022-27779: cookie for trailing dot TLD

CVE-2022-27780: percent-encoded path separator in URL host

CVE-2022-27781: CERTINFO never-ending busy-loop

CVE-2022-27782: TLS and SSH connection too eager reuse

CVE-2022-30115: HSTS bypass via trailing dot

< 7.83.1

The curl team reports:

This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. When curl is asked to pass along the hostname to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that hostname can be is 255 bytes. If the hostname is detected to be longer than 255 bytes, curl switches to local name resolving and instead passes on the resolved address only to the proxy. Due to a bug, the local variable that means "let the host resolve the name" could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too long hostname to the target buffer instead of copying just the resolved address there.

gt 7.69.0 lt 8.4.0

< 3.27.8

Harry Sintonen and Patrick Monnerat report:

CVE-2023-23914

A cleartext transmission of sensitive information vulnerability exists in curl < v7.88.0 that could cause HSTS functionality fail when multiple URLs are requested serially. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. This HSTS mechanism would however surprisingly be ignored by subsequent transfers when done on the same command line because the state would not be properly carried on.

CVE-2023-23915

A cleartext transmission of sensitive information vulnerability exists in curl < v7.88.0 that could cause HSTS functionality to behave incorrectly when multiple URLs are requested in parallel. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. This HSTS mechanism would however surprisingly fail when multiple transfers are done in parallel as the HSTS cache file gets overwritten by the most recently completed transfer. A later HTTP-only transfer to the earlier host name would then *not* get upgraded properly to HSTS.

CVE-2023-23916

An allocation of resources without limits or throttling vulnerability exists in curl < v7.88.0 based on the "chained" HTTP compression algorithms, meaning that a server response can be compressed multiple times and potentially with different algorithms. The number of acceptable "links" in this "decompression chain" was capped, but the cap was implemented on a per-header basis allowing a malicious server to insert a virtually unlimited number of compression steps simply by using many headers. The use of such a decompression chain could result in a "malloc bomb", making curl end up spending enormous amounts of allocated heap memory, or trying to and returning out of memory errors.

< 7.88.0

Wei Chong Tan, Harry Sintonen, and Hiroki Kurosawa reports:

This update fixes 4 security vulnerabilities:

• Medium CVE-2023-28319: UAF in SSH sha256 fingerprint check. Reported by Wei Chong Tan on 2023-03-21
• Low CVE-2023-28320: siglongjmp race condition. Reported by Harry Sintonen on 2023-04-02
• Low CVE-2023-28321: IDN wildcard match. Reported by Hiroki Kurosawa on 2023-04-17
• Low CVE-2023-28322: more POST-after-PUT confusion. Reported by Hiroki Kurosawa on 2023-04-19

< 8.1.0

The cURL project reports:

• OAUTH2 bearer bypass in connection re-use (CVE-2022-22576)
• Credential leak on redirect (CVE-2022-27774)
• Bad local IPv6 connection reuse (CVE-2022-27775)
• Auth/cookie leak on redirect (CVE-2022-27776)

< 7.83.0

The cURL project reports:

CURLOPT_SSLCERT mixup with Secure Transport (CVE-2021-22926)

TELNET stack contents disclosure again (CVE-2021-22925)

Bad connection reuse due to flawed path name checks (CVE-2021-92254)

Metalink download sends credentials (CVE-2021-92253)

Wrong content via metalink not discarded (CVE-2021-92252)

< 7.78.0

Harry Sintonen reports:

CVE-2023-27533

curl supports communicating using the TELNET protocol and as a part of this it offers users to pass on user name and "telnet options" for the server negotiation. Due to lack of proper input scrubbing and without it being the documented functionality, curl would pass on user name and telnet options to the server as provided. This could allow users to pass in carefully crafted content that pass on content or do option negotiation without the application intending to do so. In particular if an application for example allows users to provide the data or parts of the data.

CVE-2023-27534

curl supports SFTP transfers. curl's SFTP implementation offers a special feature in the path component of URLs: a tilde (~) character as the first path element in the path to denotes a path relative to the user's home directory. This is supported because of wording in the once proposed to-become RFC draft that was to dictate how SFTP URLs work. Due to a bug, the handling of the tilde in SFTP path did however not only replace it when it is used stand-alone as the first path element but also wrongly when used as a mere prefix in the first element. Using a path like /~2/foo when accessing a server using the user dan (with home directory /home/dan) would then quite surprisingly access the file /home/dan2/foo. This can be taken advantage of to circumvent filtering or worse.

CVE-2023-27535

libcurl would reuse a previously created FTP connection even when one or more options had been changed that could have made the effective user a very different one, thus leading to the doing the second transfer with wrong credentials. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, several FTP settings were left out from the configuration match checks, making them match too easily. The settings in questions are CURLOPT_FTP_ACCOUNT, CURLOPT_FTP_ALTERNATIVE_TO_USER, CURLOPT_FTP_SSL_CCC and CURLOPT_USE_SSL level.

CVE-2023-27536

ibcurl would reuse a previously created connection even when the GSS delegation (CURLOPT_GSSAPI_DELEGATION) option had been changed that could have changed the user's permissions in a second transfer. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, this GSS delegation setting was left out from the configuration match checks, making them match too easily, affecting krb5/kerberos/negotiate/GSSAPI transfers.

CVE-2023-27537

libcurl supports sharing HSTS data between separate "handles". This sharing was introduced without considerations for do this sharing across separate threads but there was no indication of this fact in the documentation. Due to missing mutexes or thread locks, two threads sharing the same HSTS data could end up doing a double-free or use-after-free.

CVE-2023-27538

libcurl would reuse a previously created connection even when an SSH related option had been changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, two SSH settings were left out from the configuration match checks, making them match too easily.

< 8.0.0

curl security problems:

CVE-2020-8231: wrong connect-only connection

An application that performs multiple requests with libcurl's multi API and sets the CURLOPT_CONNECT_ONLY option, might in rare circumstances experience that when subsequently using the setup connect-only transfer, libcurl will pick and use the wrong connection - and instead pick another one the application has created since then.

CURLOPT_CONNECT_ONLY is the option to tell libcurl to not perform an actual transfer, only connect. When that operation is completed, libcurl remembers which connection it used for that transfer and "easy handle". It remembers the connection using a pointer to the internal connectdata struct in memory.

If more transfers are then done with the same multi handle before the connect-only connection is used, leading to the initial connect-only connection to get closed (for example due to idle time-out) while also new transfers (and connections) are setup, such a new connection might end up getting the exact same memory address as the now closed connect-only connection.

If after those operations, the application then wants to use the original transfer's connect-only setup to for example use curl_easy_send() to send raw data over that connection, libcurl could erroneously find an existing connection still being alive at the address it remembered since before even though this is now a new and different connection.

The application could then accidentally send data over that connection which wasn't at all intended for that recipient, entirely unknowingly.

ge 7.29.0 lt 7.72.0

The cURL project reports:

• CVE-2022-32205: Set-Cookie denial of service
• CVE-2022-32206: HTTP compression denial of service
• CVE-2022-32207: Unpreserved file permissions
• CVE-2022-32208: FTP-KRB bad message verification

ge 7.16.4 lt 7.84.0