FreshPorts - VuXML

This page displays vulnerability information about FreeBSD Ports.

The VUXML data was last processed by FreshPorts on 2024-03-27 18:04:16 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
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
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
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
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
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
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
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
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
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
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
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