FreshPorts - VuXML

This page displays vulnerability information about FreeBSD Ports.

The VUXML data was last processed by FreshPorts on 2024-03-29 07:54:42 UTC

List all Vulnerabilities, by package

List all Vulnerabilities, by date

k68

These are the vulnerabilities relating to the commit you have selected:

VuXML IDDescription
01cf67b3-dc3b-11e2-a6cd-c48508086173cURL library -- heap corruption in curl_easy_unescape

cURL developers report:

libcurl is vulnerable to a case of bad checking of the input data which may lead to heap corruption.

The function curl_easy_unescape() decodes URL-encoded strings to raw binary data. URL-encoded octets are represented with %HH combinations where HH is a two-digit hexadecimal number. The decoded string is written to an allocated memory area that the function returns to the caller.

The function takes a source string and a length parameter, and if the length provided is 0 the function will instead use strlen() to figure out how much data to parse.

The "%HH" parser wrongly only considered the case where a zero byte would terminate the input. If a length-limited buffer was passed in which ended with a '%' character which was followed by two hexadecimal digits outside of the buffer libcurl was allowed to parse alas without a terminating zero, libcurl would still parse that sequence as well. The counter for remaining data to handle would then be decreased too much and wrap to become a very large integer and the copying would go on too long and the destination buffer that is allocated on the heap would get overwritten.

We consider it unlikely that programs allow user-provided strings unfiltered into this function. Also, only the not zero-terminated input string use case is affected by this flaw. Exploiting this flaw for gain is probably possible for specific circumstances but we consider the general risk for this to be low.

The curl command line tool is not affected by this problem as it doesn't use this function.

There are no known exploits available at this time.


Discovery 2013-06-22
Entry 2013-06-23
Modified 2013-07-01
curl
ge 7.7 lt 7.24.0_4

CVE-2013-2174
http://curl.haxx.se/docs/adv_20130622.html
04f29189-1a05-11e7-bc6e-b499baebfeafcURL -- potential memory disclosure

The cURL project reports:

There were two bugs in curl's parser for the command line option --write-out (or -w for short) that would skip the end of string zero byte if the string ended in a % (percent) or \ (backslash), and it would read beyond that buffer in the heap memory and it could then potentially output pieces of that memory to the terminal or the target file etc..

This flaw only exists in the command line tool.

We are not aware of any exploit of this flaw.


Discovery 2017-04-03
Entry 2017-04-05
Modified 2017-04-06
curl
ge 6.5 lt 7.53.1_1

https://curl.haxx.se/docs/adv_20170403.html
CVE-2017-7407
04fe6c8d-2a34-4009-a81e-e7a7e759b5d2cURL -- multiple vulnerabilities

cURL security problems:

CVE-2018-1000300: FTP shutdown response buffer overflow

curl might overflow a heap based memory buffer when closing down an FTP connection with very long server command replies.

When doing FTP transfers, curl keeps a spare "closure handle" around internally that will be used when an FTP connection gets shut down since the original curl easy handle is then already removed.

FTP server response data that gets cached from the original transfer might then be larger than the default buffer size (16 KB) allocated in the "closure handle", which can lead to a buffer overwrite. The contents and size of that overwrite is controllable by the server.

This situation was detected by an assert() in the code, but that was of course only preventing bad stuff in debug builds. This bug is very unlikely to trigger with non-malicious servers.

We are not aware of any exploit of this flaw.

CVE-2018-1000301: RTSP bad headers buffer over-read

curl can be tricked into reading data beyond the end of a heap based buffer used to store downloaded content.

When servers send RTSP responses back to curl, the data starts out with a set of headers. curl parses that data to separate it into a number of headers to deal with those appropriately and to find the end of the headers that signal the start of the "body" part.

The function that splits up the response into headers is called Curl_http_readwrite_headers() and in situations where it can't find a single header in the buffer, it might end up leaving a pointer pointing into the buffer instead of to the start of the buffer which then later on may lead to an out of buffer read when code assumes that pointer points to a full buffer size worth of memory to use.

This could potentially lead to information leakage but most likely a crash/denial of service for applications if a server triggers this flaw.

We are not aware of any exploit of this flaw.


Discovery 2018-05-16
Entry 2018-05-16
curl
< 7.60.0

https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/adv_2018-82c2.html
https://curl.haxx.se/docs/adv_2018-b138.html
CVE-2018-1000300
CVE-2018-1000301
0cbf0fa6-dcb7-469c-b87a-f94cffd94583cURL -- Multiple vulnerabilities

The cURL project reports:

libcurl 7.1 through 7.57.0 might accidentally leak authentication data to third parties. When asked to send custom headers in its HTTP requests, libcurl will send that set of headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the `Location:` response header value. Sending the same set of headers to subsequest hosts is in particular a problem for applications that pass on custom `Authorization:` headers, as this header often contains privacy sensitive information or data that could allow others to impersonate the libcurl-using client's request.


Discovery 2018-01-24
Entry 2018-01-26
curl
< 7.58.0

https://curl.haxx.se/docs/adv_2018-b3bf.html
CVE-2018-1000007
11e36890-d28c-11ec-a06f-d4c9ef517024curl -- 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
143ec3d6-b7cf-11e7-ac58-b499baebfeafcURL -- out of bounds read

The cURL project reports:

libcurl contains a buffer overrun flaw in the IMAP handler.

An IMAP FETCH response line indicates the size of the returned data, in number of bytes. When that response says the data is zero bytes, libcurl would pass on that (non-existing) data with a pointer and the size (zero) to the deliver-data function.

libcurl's deliver-data function treats zero as a magic number and invokes strlen() on the data to figure out the length. The strlen() is called on a heap based buffer that might not be zero terminated so libcurl might read beyond the end of it into whatever memory lies after (or just crash) and then deliver that to the application as if it was actually downloaded.


Discovery 2017-10-23
Entry 2017-10-23
curl
ge 7.20 lt 7.56.1

https://curl.haxx.se/docs/adv_20171023.html
CVE-2017-1000257
2438d4af-1538-11e5-a106-3c970e169bc2cURL -- Multiple Vulnerability

cURL reports:

libcurl can wrongly send HTTP credentials when re-using connections.

libcurl allows applications to set credentials for the upcoming transfer with HTTP Basic authentication, like with CURLOPT_USERPWD for example. Name and password. Just like all other libcurl options the credentials are sticky and are kept associated with the "handle" until something is made to change the situation.

Further, libcurl offers a curl_easy_reset() function that resets a handle back to its pristine state in terms of all settable options. A reset is of course also supposed to clear the credentials. A reset is typically used to clear up the handle and prepare it for a new, possibly unrelated, transfer.

Within such a handle, libcurl can also store a set of previous connections in case a second transfer is requested to a host name for which an existing connection is already kept alive.

With this flaw present, using the handle even after a reset would make libcurl accidentally use those credentials in a subsequent request if done to the same host name and connection as was previously accessed.

An example case would be first requesting a password protected resource from one section of a web site, and then do a second request of a public resource from a completely different part of the site without authentication. This flaw would then inadvertently leak the credentials in the second request.

libcurl can get tricked by a malicious SMB server to send off data it did not intend to.

In libcurl's state machine function handling the SMB protocol (smb_request_state()), two length and offset values are extracted from data that has arrived over the network, and those values are subsequently used to figure out what data range to send back.

The values are used and trusted without boundary checks and are just assumed to be valid. This allows carefully handcrafted packages to trick libcurl into responding and sending off data that was not intended. Or just crash if the values cause libcurl to access invalid memory.


Discovery 2015-06-17
Entry 2015-06-17
curl
ge 7.40 lt 7.43

CVE-2015-3236
CVE-2015-3237
http://curl.haxx.se/docs/adv_20150617A.html
http://curl.haxx.se/docs/adv_20150617B.html
27f742f6-03f4-11e5-aab1-d050996490d0cURL -- sensitive HTTP server headers also sent to proxies

cURL reports:

libcurl provides applications a way to set custom HTTP headers to be sent to the server by using CURLOPT_HTTPHEADER. A similar option is available for the curl command-line tool with the '--header' option.

When the connection passes through an HTTP proxy the same set of headers is sent to the proxy as well by default. While this is by design, it has not necessarily been clear nor understood by application programmers.


Discovery 2015-04-29
Entry 2015-05-26
curl
< 7.42.1

CVE-2015-3153
http://curl.haxx.se/docs/adv_20150429.html
301a01b7-d50e-11e7-ac58-b499baebfeafcURL -- Multiple vulnerabilities

The cURL project reports:

  • NTLM buffer overflow via integer overflow (CVE-2017-8816)

    libcurl contains a buffer overrun flaw in the NTLM authentication code. The internal function Curl_ntlm_core_mk_ntlmv2_hash sums up the lengths of the user name + password (= SUM) and multiplies the sum by two (= SIZE) to figure out how large storage to allocate from the heap.
  • FTP wildcard out of bounds read (CVE-2017-8817)

    libcurl contains a read out of bounds flaw in the FTP wildcard function. libcurl's FTP wildcard matching feature, which is enabled with the CURLOPT_WILDCARDMATCH option can use a built-in wildcard function or a user provided one. The built-in wildcard function has a flaw that makes it not detect the end of the pattern string if it ends with an open bracket ([) but instead it will continue reading the heap beyond the end of the URL buffer that holds the wildcard.
  • SSL out of buffer access (CVE-2017-8818)

    libcurl contains an out boundary access flaw in SSL related code. When allocating memory for a connection (the internal struct called connectdata), a certain amount of memory is allocated at the end of the struct to be used for SSL related structs. Those structs are used by the particular SSL library libcurl is built to use. The application can also tell libcurl which specific SSL library to use if it was built to support more than one.

Discovery 2017-11-29
Entry 2017-11-29
Modified 2017-12-11
curl
ge 7.21.0 lt 7.57.0

linux-c7-curl
ge 7.21.0 lt 7.29.0_4

https://curl.haxx.se/changes.html
CVE-2017-8816
CVE-2017-8817
CVE-2017-8818
311e4b1c-f8ee-11e6-9940-b499baebfeafcURL -- ocsp status validation error

The cURL project reports:

SSL_VERIFYSTATUS ignored

curl and libcurl support "OCSP stapling", also known as the TLS Certificate Status Request extension (using the CURLOPT_SSL_VERIFYSTATUS option). When telling curl to use this feature, it uses that TLS extension to ask for a fresh proof of the server's certificate's validity. If the server doesn't support the extension, or fails to provide said proof, curl is expected to return an error.

Due to a coding mistake, the code that checks for a test success or failure, ends up always thinking there's valid proof, even when there is none or if the server doesn't support the TLS extension in question. Contrary to how it used to function and contrary to how this feature is documented to work.

This could lead to users not detecting when a server's certificate goes invalid or otherwise be mislead that the server is in a better shape than it is in reality.


Discovery 2017-02-22
Entry 2017-02-22
curl
ge 7.52.0 lt 7.53.0

https://curl.haxx.se/docs/adv_20170222.html
CVE-2017-2629
3849e28f-8693-11e8-9610-9c5c8e75236acurl -- SMTP send heap buffer overflow

Peter Wu reports:

curl might overflow a heap based memory buffer when sending data over SMTP and using a reduced read buffer.


Discovery 2018-07-11
Entry 2018-07-27
Modified 2018-07-28
curl
ge 7.54.1 lt 7.61.0

https://curl.haxx.se/docs/adv_2018-70a2.html
CVE-2018-0500
3c77f139-3a09-11eb-929d-d4c9ef517024cURL -- 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
3e2e9b44-25ce-11e7-a175-939b30e0836dcURL -- TLS session resumption client cert bypass (again)

cURL security advisory:

libcurl would attempt to resume a TLS session even if the client certificate had changed. That is unacceptable since a server by specification is allowed to skip the client certificate check on resume, and may instead use the old identity which was established by the previous certificate (or no certificate).

libcurl supports by default the use of TLS session id/ticket to resume previous TLS sessions to speed up subsequent TLS handshakes. They are used when for any reason an existing TLS connection couldn't be kept alive to make the next handshake faster.

This flaw is a regression and identical to CVE-2016-5419 reported on August 3rd 2016, but affecting a different version range.


Discovery 2017-04-19
Entry 2017-04-20
curl
ge 7.52.0 lt 7.54.0

CVE-2017-7468
https://curl.haxx.se/docs/adv_20170419.html
42880202-c81c-11e6-a9a5-b499baebfeafcURL -- buffer overflow

The cURL project reports:

printf floating point buffer overflow

libcurl's implementation of the printf() functions triggers a buffer overflow when doing a large floating point output. The bug occurs when the conversion outputs more than 255 bytes.


Discovery 2016-12-21
Entry 2016-12-22
curl
ge 7.1 lt 7.52

https://curl.haxx.se/docs/vuln-7.51.0.html
CVE-2016-9586
4e1f4abc-6837-11e3-9cda-3c970e169bc2cURL library -- cert name check ignore with GnuTLS

cURL project reports:

libcurl is vulnerable to a case of missing out the checking of the certificate CN or SAN name field when the digital signature verification is turned off.

libcurl offers two separate and independent options for verifying a server's TLS certificate. CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST. The first one tells libcurl to verify the trust chain using a CA cert bundle, while the second tells libcurl to make sure that the name fields in the server certificate meets the criteria. Both options are enabled by default.

This flaw had the effect that when an application disabled CURLOPT_SSL_VERIFYPEER, libcurl mistakenly also skipped the CURLOPT_SSL_VERIFYHOST check. Applications can disable CURLOPT_SSL_VERIFYPEER and still achieve security by doing the check on its own using other means.

The curl command line tool is not affected by this problem as it either enables both options or disables both at the same time.


Discovery 2013-12-17
Entry 2013-12-18
curl
ge 7.21.4 lt 7.33.0_2

http://curl.haxx.se/docs/adv_20131217.html
CVE-2013-6422
5d433534-f41c-402e-ade5-e0a2259a7cb6curl -- cURL/libcURL Location: Redirect URLs Security Bypass

Secunia reports:

The security issue is caused due to cURL following HTTP Location: redirects to e.g. scp:// or file:// URLs which can be exploited by a malicious HTTP server to overwrite or disclose the content of arbitrary local files and potentially execute arbitrary commands via specially crafted redirect URLs.


Discovery 2009-03-03
Entry 2009-03-04
curl
ge 5.11 lt 7.19.4

CVE-2009-0037
http://secunia.com/advisories/34138/
6294f75f-03f2-11e5-aab1-d050996490d0cURL -- multiple vulnerabilities

cURL reports:

libcurl keeps a pool of its last few connections around after use to facilitate easy, convenient, and completely transparent connection re-use for applications.

When doing HTTP requests NTLM authenticated, the entire connection becomes authenticated and not just the specific HTTP request which is otherwise how HTTP works. This makes NTLM special and a subject for special treatment in the code. With NTLM, once the connection is authenticated, no further authentication is necessary until the connection gets closed.

When doing HTTP requests Negotiate authenticated, the entire connection may become authenticated and not just the specific HTTP request which is otherwise how HTTP works, as Negotiate can basically use NTLM under the hood. curl was not adhering to this fact but would assume that such requests would also be authenticated per request.

libcurl supports HTTP "cookies" as documented in RFC 6265. Together with each individual cookie there are several different properties, but for this vulnerability we focus on the associated "path" element. It tells information about for which path on a given host the cookies is valid.

The internal libcurl function called sanitize_cookie_path() that cleans up the path element as given to it from a remote site or when read from a file, did not properly validate the input. If given a path that consisted of a single double-quote, libcurl would index a newly allocated memory area with index -1 and assign a zero to it, thus destroying heap memory it wasn't supposed to.

There is a private function in libcurl called fix_hostname() that removes a trailing dot from the host name if there is one. The function is called after the host name has been extracted from the URL libcurl has been told to act on.

If a URL is given with a zero-length host name, like in "http://:80" or just ":80", fix_hostname() will index the host name pointer with a -1 offset (as it blindly assumes a non-zero length) and both read and assign that address.


Discovery 2015-04-22
Entry 2015-05-26
curl
< 7.42.0

http://curl.haxx.se/docs/adv_20150422A.html
http://curl.haxx.se/docs/adv_20150422B.html
http://curl.haxx.se/docs/adv_20150422C.html
http://curl.haxx.se/docs/adv_20150422D.html
CVE-2014-3143
CVE-2014-3144
CVE-2014-3145
CVE-2014-3148
69cfa386-7cd0-11e7-867f-b499baebfeafcURL -- multiple vulnerabilities

The cURL project reports:

  • FILE buffer read out of bounds
  • TFTP sends more than buffer size
  • URL globbing out of bounds read

Discovery 2017-08-09
Entry 2017-08-09
curl
< 7.55.0

https://curl.haxx.se/docs/security.html
CVE-2017-1000099
CVE-2017-1000100
CVE-2017-1000101
6bff5ca6-b61a-11ea-aef4-08002728f74ccurl -- 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
714b033a-2b09-11e9-8bc3-610fd6e6cd05curl -- multiple vulnerabilities

curl security problems:

CVE-2018-16890: NTLM type-2 out-of-bounds buffer read

libcurl contains a heap buffer out-of-bounds read flaw.

The function handling incoming NTLM type-2 messages (lib/vauth/ntlm.c:ntlm_decode_type2_target) does not validate incoming data correctly and is subject to an integer overflow vulnerability.

Using that overflow, a malicious or broken NTLM server could trick libcurl to accept a bad length + offset combination that would lead to a buffer read out-of-bounds.

CVE-2019-3822: NTLMv2 type-3 header stack buffer overflow

libcurl contains a stack based buffer overflow vulnerability.

The function creating an outgoing NTLM type-3 header (lib/vauth/ntlm.c:Curl_auth_create_ntlm_type3_message()), generates the request HTTP header contents based on previously received data. The check that exists to prevent the local buffer from getting overflowed is implemented wrongly (using unsigned math) and as such it does not prevent the overflow from happening.

This output data can grow larger than the local buffer if very large "nt response" data is extracted from a previous NTLMv2 header provided by the malicious or broken HTTP server.

Such a "large value" needs to be around 1000 bytes or more. The actual payload data copied to the target buffer comes from the NTLMv2 type-2 response header.

CVE-2019-3823: SMTP end-of-response out-of-bounds read

libcurl contains a heap out-of-bounds read in the code handling the end-of-response for SMTP.

If the buffer passed to smtp_endofresp() isn't NUL terminated and contains no character ending the parsed number, and len is set to 5, then the strtol() call reads beyond the allocated buffer. The read contents will not be returned to the caller.


Discovery 2019-02-07
Entry 2019-02-07
curl
< 7.64.0

https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2018-16890.html
https://curl.haxx.se/docs/CVE-2019-3822.html
https://curl.haxx.se/docs/CVE-2019-3823.html
CVE-2018-16890
CVE-2019-3822
CVE-2019-3823
765feb7d-a0d1-11e6-a881-b499baebfeafcURL -- multiple vulnerabilities

The cURL project reports

  • cookie injection for other servers
  • case insensitive password comparison
  • OOB write via unchecked multiplication
  • double-free in curl_maprintf
  • double-free in krb5 code
  • glob parser write/read out of bounds
  • curl_getdate read out of bounds
  • URL unescape heap overflow via integer truncation
  • Use-after-free via shared cookies
  • invalid URL parsing with '#'
  • IDNA 2003 makes curl use wrong host

Discovery 2016-11-02
Entry 2016-11-02
curl
ge 7.1 lt 7.51.0

https://curl.haxx.se/docs/security.html
CVE-2016-8615
CVE-2016-8616
CVE-2016-8617
CVE-2016-8618
CVE-2016-8619
CVE-2016-8620
CVE-2016-8621
CVE-2016-8622
CVE-2016-8623
CVE-2016-8624
CVE-2016-8625
8b27f1bc-c509-11e5-a95f-b499baebfeafcurl -- Credentials not checked

The cURL project reports:

libcurl will reuse NTLM-authenticated proxy connections without properly making sure that the connection was authenticated with the same credentials as set for this transfer.


Discovery 2016-01-27
Entry 2016-01-27
Modified 2017-02-06
curl
ge 7.10.0 lt 7.47.0

http://curl.haxx.se/docs/adv_20160127A.html
CVE-2016-0755
92a4d881-c6cf-11ec-a06f-d4c9ef517024cURL -- 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
9314058e-5204-11e7-b712-b1a44a034d72cURL -- URL file scheme drive letter buffer overflow

cURL security advisory:

When libcurl is given either

1. a file: URL that doesn't use two slashes following the colon, or

2. is told that file is the default scheme to use for URLs without scheme

... and the given path starts with a drive letter and libcurl is built for Windows or DOS, then libcurl would copy the path with a wrong offset, so that the end of the given path would write beyond the malloc buffer. Up to seven bytes too much.

We are not aware of any exploit of this flaw.


Discovery 2017-06-14
Entry 2017-06-15
curl
ge 7.53.0 lt 7.54.1

CVE-2017-9502
https://curl.haxx.se/docs/adv_20170614.html
96df5fd0-8900-11d9-aa18-0001020eed82curl -- authentication buffer overflow vulnerability

Two iDEFENSE Security Advisories reports:

An exploitable stack-based buffer overflow condition exists when using NT Lan Manager (NTLM) authentication. The problem specifically exists within Curl_input_ntlm() defined in lib/http_ntlm.c.

Successful exploitation allows remote attackers to execute arbitrary code under the privileges of the target user. Exploitation requires that an attacker either coerce or force a target to connect to a malicious server using NTLM authentication.

An exploitable stack-based buffer overflow condition exists when using Kerberos authentication. The problem specifically exists within the functions Curl_krb_kauth() and krb4_auth() defined in lib/krb4.c.

Successful exploitation allows remote attackers to execute arbitrary code under the privileges of the target user. Exploitation requires that an attacker either coerce or force a target to connect to a malicious server using Kerberos authentication.


Discovery 2004-12-21
Entry 2005-02-27
curl
< 7.13.1

12615
12616
CVE-2005-0490
http://marc.theaimsgroup.com/?l=bugtraq&m=110902850731457
http://marc.theaimsgroup.com/?l=bugtraq&m=110902601221592
9aecb94c-c1ad-11e3-a5ac-001b21614864cURL -- inappropriate GSSAPI delegation

cURL reports:

When doing GSSAPI authentication, libcurl unconditionally performs credential delegation. This hands the server a copy of the client's security credentials, allowing the server to impersonate the client to any other using the same GSSAPI mechanism.


Discovery 2011-06-23
Entry 2014-04-11
Modified 2014-04-30
curl
ge 7.10.6 le 7.21.6

linux-f10-curl
ge 7.10.6 le 7.21.6

CVE-2011-2192
http://curl.haxx.se/docs/adv_20110623.html
9b4facec-6761-11da-99f6-00123ffe8333curl -- URL buffer overflow vulnerability

A Project cURL Security Advisory reports:

libcurl's URL parser function can overflow a malloced buffer in two ways, if given a too long URL.

1 - pass in a URL with no protocol (like "http://") prefix, using no slash and the string is 256 bytes or longer. This leads to a single zero byte overflow of the malloced buffer.

2 - pass in a URL with only a question mark as separator (no slash) between the host and the query part of the URL. This leads to a single zero byte overflow of the malloced buffer.

Both overflows can be made with the same input string, leading to two single zero byte overwrites.

The affected flaw cannot be triggered by a redirect, but the long URL must be passed in "directly" to libcurl. It makes this a "local" problem. Of course, lots of programs may still pass in user-provided URLs to libcurl without doing much syntax checking of their own, allowing a user to exploit this vulnerability.


Discovery 2005-12-07
Entry 2005-12-09
Modified 2006-01-01
curl
ge 7.11.2 lt 7.15.1

15756
CVE-2005-4077
http://curl.haxx.se/docs/adv_20051207.html
http://www.hardened-php.net/advisory_242005.109.html
http://secunia.com/advisories/17907/
9fb4e57b-d65a-11e9-8a5f-e5c82b486287curl -- multiple vulnerabilities

curl security problems:

CVE-2019-5481: FTP-KRB double-free

libcurl can be told to use kerberos over FTP to a server, as set with the CURLOPT_KRBLEVEL option.

During such kerberos FTP data transfer, the server sends data to curl in blocks with the 32 bit size of each block first and then that amount of data immediately following.

A malicious or just broken server can claim to send a very large block and if by doing that it makes curl's subsequent call to realloc() to fail, curl would then misbehave in the exit path and double-free the memory.

In practical terms, an up to 4 GB memory area may very well be fine to allocate on a modern 64 bit system but on 32 bit systems it will fail.

Kerberos FTP is a rarely used protocol with curl. Also, Kerberos authentication is usually only attempted and used with servers that the client has a previous association with.

CVE-2019-5482: TFTP small blocksize heap buffer overflow

libcurl contains a heap buffer overflow in the function (tftp_receive_packet()) that receives data from a TFTP server. It can call recvfrom() with the default size for the buffer rather than with the size that was used to allocate it. Thus, the content that might overwrite the heap memory is controlled by the server.

This flaw is only triggered if the TFTP server sends an OACK without the BLKSIZE option, when a BLKSIZE smaller than 512 bytes was requested by the TFTP client. OACK is a TFTP extension and is not used by all TFTP servers.

Users choosing a smaller block size than default should be rare as the primary use case for changing the size is to make it larger.

It is rare for users to use TFTP across the Internet. It is most commonly used within local networks. TFTP as a protocol is always inherently insecure.

This issue was introduced by the add of the TFTP BLKSIZE option handling. It was previously incompletely fixed by an almost identical issue called CVE-2019-5436.


Discovery 2019-09-11
Entry 2019-09-14
curl
ge 7.19.4 lt 7.66.0

https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2019-5481.html
https://curl.haxx.se/docs/CVE-2019-5482.html
CVE-2019-5481
CVE-2019-5482
aa646c01-ea0d-11eb-9b84-d4c9ef517024cURL -- 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
ae5722a6-f5f0-11ec-856e-d4c9ef517024cURL -- 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
b018121b-7a4b-11e6-bf52-b499baebfeafcURL -- Escape and unescape integer overflows

The cURL project reports

The four libcurl functions curl_escape(), curl_easy_escape(), curl_unescape and curl_easy_unescape perform string URL percent escaping and unescaping. They accept custom string length inputs in signed integer arguments.

The provided string length arguments were not properly checked and due to arithmetic in the functions, passing in the length 0xffffffff (2^32-1 or UINT_MAX or even just -1) would end up causing an allocation of zero bytes of heap memory that curl would attempt to write gigabytes of data into.


Discovery 2016-09-14
Entry 2016-09-14
curl
ge 7.11.1 lt 7.50.3

https://curl.haxx.se/docs/adv_20160914.html
CVE-2016-7167
b1194286-958e-11eb-9c34-080027f515eacurl -- 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
b8e361b8-b7ff-11da-8414-0013d4a4a40ecurl -- TFTP packet buffer overflow vulnerability

A Project cURL Security Advisory reports:

libcurl uses the given file part of a TFTP URL in a manner that allows a malicious user to overflow a heap-based memory buffer due to the lack of boundary check.

This overflow happens if you pass in a URL with a TFTP protocol prefix ("tftp://"), using a valid host and a path part that is longer than 512 bytes.

The affected flaw can be triggered by a redirect, if curl/libcurl is told to follow redirects and an HTTP server points the client to a tftp URL with the characteristics described above.


Discovery 2006-03-20
Entry 2006-03-20
Modified 2006-10-05
curl
linux-curl
gt 7.14.1 lt 7.15.3

CVE-2006-1061
http://curl.haxx.se/docs/adv_20060320.html
b905dff4-e227-11ea-b0ea-08002728f74ccurl -- 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
c40ca16c-4d9f-4d70-8b6c-4d53aeb8ead4cURL -- uninitialized random vulnerability

Project curl Security Advisory:

libcurl's (new) internal function that returns a good 32bit random value was implemented poorly and overwrote the pointer instead of writing the value into the buffer the pointer pointed to.

This random value is used to generate nonces for Digest and NTLM authentication, for generating boundary strings in HTTP formposts and more. Having a weak or virtually non-existent random there makes these operations vulnerable.

This function is brand new in 7.52.0 and is the result of an overhaul to make sure libcurl uses strong random as much as possible - provided by the backend TLS crypto libraries when present. The faulty function was introduced in this commit.

We are not aware of any exploit of this flaw.


Discovery 2016-12-23
Entry 2016-12-24
curl
ge 7.52.0 lt 7.52.1

https://curl.haxx.se/docs/adv_20161223.html
CVE-2016-9594
c8c31c41-49ed-11df-83fb-0015587e2cc1curl -- libcurl buffer overflow vulnerability

The cURL project reports in a security advisory:

Using the affected libcurl version to download compressed content over HTTP, an application can ask libcurl to automatically uncompress data. When doing so, libcurl can wrongly send data up to 64K in size to the callback which thus is much larger than the documented maximum size.

An application that blindly trusts libcurl's max limit for a fixed buffer size or similar is then a possible target for a buffer overflow vulnerability.


Discovery 2010-02-09
Entry 2010-04-19
curl
ge 7.10.5 lt 7.20.0

CVE-2010-0734
http://curl.haxx.se/docs/adv_20100209.html
http://www.debian.org/security/2010/dsa-2023
http://www.openwall.com/lists/oss-security/2010/02/09/5
c9221ec9-17a2-11ec-b335-d4c9ef517024cURL -- 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
caa98ffd-0a92-40d0-b234-fd79b429157ecURL -- URL request injection vulnerability

cURL reports:

When libcurl sends a request to a server via a HTTP proxy, it copies the entire URL into the request and sends if off. If the given URL contains line feeds and carriage returns those will be sent along to the proxy too, which allows the program to for example send a separate HTTP request injected embedded in the URL. Many programs allow some kind of external sources to set the URL or provide partial pieces for the URL to ask for, and if the URL as received from the user is not stripped good enough this flaw allows malicious users to do additional requests in a way that was not intended, or just to insert request headers into the request that the program didn't intend. We are not aware of any exploit of this flaw.


Discovery 2014-12-25
Entry 2015-01-09
curl
< 7.40.0

CVE-2014-8150
http://curl.haxx.se/docs/adv_20150108B.html
ccace707-a8d8-11e7-ac58-b499baebfeafcURL -- out of bounds read

The cURL project reports:

FTP PWD response parser out of bounds read

libcurl may read outside of a heap allocated buffer when doing FTP.

When libcurl connects to an FTP server and successfully logs in (anonymous or not), it asks the server for the current directory with the PWD command. The server then responds with a 257 response containing the path, inside double quotes. The returned path name is then kept by libcurl for subsequent uses.

Due to a flaw in the string parser for this directory name, a directory name passed like this but without a closing double quote would lead to libcurl not adding a trailing NUL byte to the buffer holding the name. When libcurl would then later access the string, it could read beyond the allocated heap buffer and crash or wrongly access data beyond the buffer, thinking it was part of the path.

A malicious server could abuse this fact and effectively prevent libcurl-based clients to work with it - the PWD command is always issued on new FTP connections and the mistake has a high chance of causing a segfault.


Discovery 2017-10-04
Entry 2017-10-04
curl
< 7.56.0

https://curl.haxx.se/docs/adv_20171004.html
CVE-2017-1000254
d10fc771-958f-11eb-9c34-080027f515eacurl -- 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
dd343a2b-7ee7-11e9-a290-8ddc52868fa9curl -- multiple vulnerabilities

curl security problems:

CVE-2019-5435: Integer overflows in curl_url_set()

libcurl contains two integer overflows in the curl_url_set() function that if triggered, can lead to a too small buffer allocation and a subsequent heap buffer overflow.

The flaws only exist on 32 bit architectures and require excessive string input lengths.

CVE-2019-5436: TFTP receive buffer overflow

libcurl contains a heap buffer overflow in the function (tftp_receive_packet()) that recevives data from a TFTP server. It calls recvfrom() with the default size for the buffer rather than with the size that was used to allocate it. Thus, the content that might overwrite the heap memory is entirely controlled by the server.

The flaw exists if the user selects to use a "blksize" of 504 or smaller (default is 512). The smaller size that is used, the larger the possible overflow becomes.

Users chosing a smaller size than default should be rare as the primary use case for changing the size is to make it larger.

It is rare for users to use TFTP across the Internet. It is most commonly used within local networks.


Discovery 2019-05-22
Entry 2019-05-25
Modified 2019-05-26
curl
ge 7.19.4 lt 7.65.0

https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2019-5435.html
https://curl.haxx.se/docs/CVE-2019-5436.html
CVE-2019-5435
CVE-2019-5436
e0ab1773-07c1-46c6-9170-4c5e81c00927curl -- multiple vulnerabilities

curl security problems:

CVE-2018-16839: SASL password overflow via integer overflow

libcurl contains a buffer overrun in the SASL authentication code.

The internal function Curl_auth_create_plain_message fails to correctly verify that the passed in lengths for name and password aren't too long, then calculates a buffer size to allocate.

On systems with a 32 bit size_t, the math to calculate the buffer size triggers an integer overflow when the user name length exceeds 2GB (2^31 bytes). This integer overflow usually causes a very small buffer to actually get allocated instead of the intended very huge one, making the use of that buffer end up in a heap buffer overflow.

This bug is very similar to CVE-2017-14618.

It affects curl 7.33.0 to 7.61.1.

CVE-2018-16840: use-after-free in handle close

libcurl contains a heap use-after-free flaw in code related to closing an easy handle.

When closing and cleaning up an "easy" handle in the Curl_close() function, the library code first frees a struct (without nulling the pointer) and might then subsequently erroneously write to a struct field within that already freed struct.

It affects curl 7.59.0 to 7.61.1.

CVE-2018-16842: warning message out-of-buffer read

curl contains a heap out of buffer read vulnerability.

The command line tool has a generic function for displaying warning and informational messages to stderr for various situations. For example if an unknown command line argument is used, or passed to it in a "config" file.

This display function formats the output to wrap at 80 columns. The wrap logic is however flawed, so if a single word in the message is itself longer than 80 bytes the buffer arithmetic calculates the remainder wrong and will end up reading behind the end of the buffer. This could lead to information disclosure or crash.

This vulnerability could lead to a security issue if used in this or similar situations:

1. a server somewhere uses the curl command line to run something

2. if it fails, it shows stderr to the user

3. the server takes user input for parts of its command line input

4. user provides something overly long that triggers this crash

5. the stderr output may now contain user memory contents that wasn't meant to be available

It affects curl 7.14.1 to 7.61.1.


Discovery 2018-10-31
Entry 2018-11-01
curl
ge 7.14.1 lt 7.60.0

https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2018-16839.html
https://curl.haxx.se/docs/CVE-2018-16840.html
https://curl.haxx.se/docs/CVE-2018-16842.html
CVE-2018-16839
CVE-2018-16840
CVE-2018-16842
e4bc70fc-5a2f-11e6-a1bc-589cfc0654e1Vulnerabilities in Curl

Curl security team reports:

CVE-2016-5419 - TLS session resumption client cert bypass

CVE-2016-5420 - Re-using connections with wrong client cert

CVE-2016-5421 - use of connection struct after free


Discovery 2016-08-03
Entry 2016-08-04
curl
ge 7.32.0 lt 7.50.1

CVE-2016-5419
CVE-2016-5420
CVE-2016-5421
https://curl.haxx.se/docs/adv_20160803A.html
https://curl.haxx.se/docs/adv_20160803B.html
https://curl.haxx.se/docs/adv_20160803C.html
f4d638b9-e6e5-4dbe-8c70-571dbc116174curl -- password overflow vulnerability

curl security problems:

CVE-2018-14618: NTLM password overflow via integer overflow

The internal function Curl_ntlm_core_mk_nt_hash multiplies the length of the password by two (SUM) to figure out how large temporary storage area to allocate from the heap.

The length value is then subsequently used to iterate over the password and generate output into the allocated storage buffer. On systems with a 32 bit size_t, the math to calculate SUM triggers an integer overflow when the password length exceeds 2GB (2^31 bytes). This integer overflow usually causes a very small buffer to actually get allocated instead of the intended very huge one, making the use of that buffer end up in a heap buffer overflow.

This bug is almost identical to CVE-2017-8816.


Discovery 2018-09-05
Entry 2018-09-05
Modified 2019-08-03
curl
ge 7.15.4 lt 7.61.1

linux-c7-curl
< 7.29.0_6

https://curl.haxx.se/docs/security.html
https://curl.haxx.se/docs/CVE-2018-14618.html
CVE-2018-14618