FreeBSD: VID-6BFF5CA6-B61A-11EA-AEF4-08002728F74C (CVE-2020-8177): curl -- multiple vulnerabilities

Description

Details for this vulnerability have not been published by NIST at this point. Descriptions from software vendor advisories for this issue are provided below.

From VID-6BFF5CA6-B61A-11EA-AEF4-08002728F74C:

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