VuXML ID | Description |
3c77f139-3a09-11eb-929d-d4c9ef517024 | cURL -- Multiple vulnerabilities
The cURL project reports:
Trusting FTP PASV responses (CVE-2020-8284)
FTP wildcard stack overflow (CVE-2020-8285)
Inferior OCSP verification (CVE-2020-8286)
Discovery 2020-12-09 Entry 2020-12-09 curl
gt 4.0 lt 7.74.0
https://curl.se/docs/security.html
CVE-2020-8284
CVE-2020-8285
CVE-2020-8286
|
833b469b-5247-11ee-9667-080027f5fec9 | curl -- HTTP headers eat all memory
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.
Discovery 2023-09-13 Entry 2023-09-13 curl
< 8.3.0
CVE-2023-38039
https://curl.se/docs/CVE-2023-38039.html HERE
|
b1194286-958e-11eb-9c34-080027f515ea | curl -- Automatic referer leaks credentials
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".
Discovery 2021-03-31 Entry 2021-04-10 curl
ge 7.1.1 lt 7.76.0
CVE-2021-22876
https://curl.se/docs/CVE-2021-22876.html
|
b905dff4-e227-11ea-b0ea-08002728f74c | curl -- expired pointer dereference vulnerability
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.
Discovery 2020-08-19 Entry 2020-08-19 curl
ge 7.29.0 lt 7.72.0
https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2020-8231.html
CVE-2020-8231
|
6bff5ca6-b61a-11ea-aef4-08002728f74c | curl -- multiple vulnerabilities
curl security problems:
CVE-2020-8169: Partial password leak over DNS on HTTP redirect
libcurl can be tricked to prepend a part of the password to the
host name before it resolves it, potentially leaking the partial
password over the network and to the DNS server(s).
libcurl can be given a username and password for HTTP
authentication when requesting an HTTP resource - used for HTTP
Authentication such as Basic, Digest, NTLM and similar. The
credentials are set, either together with CURLOPT_USERPWD or
separately with CURLOPT_USERNAME and CURLOPT_PASSWORD. Important
detail: these strings are given to libcurl as plain C strings and
they are not supposed to be URL encoded.
In addition, libcurl also allows the credentials to be set in the
URL, using the standard RFC 3986 format:
http://user:password@host/path. In this case, the name and password
are URL encoded as that's how they appear in URLs.
If the options are set, they override the credentials set in the
URL.
Internally, this is handled by storing the credentials in the "URL
object" so that there is only a single set of credentials stored
associated with this single URL.
When libcurl handles a relative redirect (as opposed to an
absolute URL redirect) for an HTTP transfer, the server is only
sending a new path to the client and that path is applied on to the
existing URL. That "applying" of the relative path on top of an
absolute URL is done by libcurl first generating a full absolute
URL out of all the components it has, then it applies the redirect
and finally it deconstructs the URL again into its separate
components.
This security vulnerability originates in the fact that curl did
not correctly URL encode the credential data when set using one of
the curl_easy_setopt options described above. This made curl
generate a badly formatted full URL when it would do a redirect and
the final re-parsing of the URL would then go bad and wrongly
consider a part of the password field to belong to the host name.
The wrong host name would then be used in a name resolve lookup,
potentially leaking the host name + partial password in clear text
over the network (if plain DNS was used) and in particular to the
used DNS server(s).
CVE-2020-8177: curl overwrite local file with -J
curl can be tricked by a malicious server to overwrite a local
file when using -J (--remote-header-name) and -i (--include) in the
same command line.
The command line tool offers the -J option that saves a remote
file using the file name present in the Content-Disposition:
response header. curl then refuses to overwrite an existing local
file using the same name, if one already exists in the current
directory.
The -J flag is designed to save a response body, and so it doesn't
work together with -i and there's logic that forbids it. However,
the check is flawed and doesn't properly check for when the options
are used in the reversed order: first using -J and then -i were
mistakenly accepted.
The result of this mistake was that incoming HTTP headers could
overwrite a local file if one existed, as the check to avoid the
local file was done first when body data was received, and due to
the mistake mentioned above, it could already have received and
saved headers by that time.
The saved file would only get response headers added to it, as it
would abort the saving when the first body byte arrives. A
malicious server could however still be made to send back virtually
anything as headers and curl would save them like this, until the
first CRLF-CRLF sequence appears.
(Also note that -J needs to be used in combination with -O to have
any effect.)
Discovery 2020-06-24 Entry 2020-06-24 curl
ge 7.20.0 lt 7.71.0
https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2020-8169.html
https://curl.haxx.se/docs/CVE-2020-8177.html
CVE-2020-8169
CVE-2020-8177
|
be233fc6-bae7-11ed-a4fb-080027f5fec9 | curl -- multiple vulnerabilities
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.
Discovery 2023-02-15 Entry 2023-03-05 curl
< 7.88.0
CVE-2023-23914
CVE-2023-23915
CVE-2023-23916
https://curl.se/docs/security.html
|
0d7d104c-c6fb-11ed-8a4b-080027f5fec9 | curl -- multiple vulnerabilities
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.
Discovery 2023-03-20 Entry 2023-03-20 curl
< 8.0.0
CVE-2023-27533
CVE-2023-27534
CVE-2023-27535
CVE-2023-27536
CVE-2023-27537
CVE-2023-27538
https://curl.se/docs/security.html
|
02e33cd1-c655-11ee-8613-08002784c58d | curl -- OCSP verification bypass with TLS session reuse
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.
Discovery 2024-01-31 Entry 2024-02-28 curl
< 8.6.0
CVE-2024-0853
https://curl.se/docs/CVE-2024-0853.html
|
d10fc771-958f-11eb-9c34-080027f515ea | curl -- TLS 1.3 session ticket proxy host mixup
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.
Discovery 2021-03-31 Entry 2021-04-10 curl
ge 7.63.0 lt 7.76.0
CVE-2021-22890
https://curl.se/docs/CVE-2021-22890.html
|
aa646c01-ea0d-11eb-9b84-d4c9ef517024 | cURL -- Multiple vulnerabilities
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)
Discovery 2021-07-21 Entry 2021-07-21 curl
< 7.78.0
CVE-2021-22922
CVE-2021-22923
CVE-2021-22924
CVE-2021-22925
CVE-2021-22926
https://curl.se/docs/vuln-7.77.0.html
|
11e36890-d28c-11ec-a06f-d4c9ef517024 | curl -- Multiple vulnerabilities
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
Discovery 2022-05-11 Entry 2022-05-13 curl
< 7.83.1
CVE-2022-27778
CVE-2022-27779
CVE-2022-27780
CVE-2022-27781
CVE-2022-27782
CVE-2022-30115
https://curl.se/docs/security.html
|
c9221ec9-17a2-11ec-b335-d4c9ef517024 | cURL -- Multiple vulnerabilities
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)
Discovery 2021-09-15 Entry 2021-09-17 Modified 2021-09-28 curl
ge 7.20.0 lt 7.79.0
CVE-2021-22945
CVE-2021-22946
CVE-2021-22947
https://curl.se/docs/security.html
|
0f99a30c-7b4b-11ed-9168-080027f5fec9 | curl -- multiple vulnerabilities
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ãÂÂ
Discovery 2022-10-26 Entry 2022-12-14 curl
< 7.86.0
CVE-2022-32221
CVE-2022-35260
CVE-2022-42915
CVE-2022-42916
https://curl.se/docs/CVE-2022-32221.html
https://curl.se/docs/CVE-2022-35260.html
https://curl.se/docs/CVE-2022-42915.html
https://curl.se/docs/CVE-2022-42916.html
|
92a4d881-c6cf-11ec-a06f-d4c9ef517024 | cURL -- Multiple vulnerabilities
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)
Discovery 2022-04-27 Entry 2022-04-28 curl
< 7.83.0
CVE-2022-22576
CVE-2022-27774
CVE-2022-27775
CVE-2022-27776
https://curl.se/docs/vuln-7.82.0.html
|
a4f8bb03-f52f-11ed-9859-080027083a05 | curl -- multiple vulnerabilities
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
Discovery 2023-03-21 Entry 2023-05-19 curl
< 8.1.0
CVE-2023-28319
https://curl.se/docs/CVE-2023-28319.html
CVE-2023-28320
https://curl.se/docs/CVE-2023-28320.html
CVE-2023-28321
https://curl.se/docs/CVE-2023-28321.html
CVE-2023-28322
https://curl.se/docs/CVE-2023-28322.html
|
ae5722a6-f5f0-11ec-856e-d4c9ef517024 | cURL -- Multiple vulnerabilities
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
Discovery 2022-06-27 Entry 2022-06-27 curl
ge 7.16.4 lt 7.84.0
CVE-2022-32205
CVE-2022-32206
CVE-2022-32207
CVE-2022-32208
https://curl.se/docs/security.html
|