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