CURL-CVE-2020-8169

Source
https://curl.se/docs/CVE-2020-8169.html
Import Source
https://curl.se/docs/CURL-CVE-2020-8169.json
JSON Data
https://api.osv.dev/v1/vulns/CURL-CVE-2020-8169
Aliases
Published
2020-06-24T08:00:00Z
Modified
2024-06-07T13:53:51Z
Summary
Partial password leak over DNS on HTTP redirect
Details

libcurl can be tricked to prepend a part of the password to the hostname 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 is 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 hostname would then be used in a name resolve lookup, potentially leaking the hostname + partial password in clear text over the network (if plain DNS was used) and in particular to the used DNS server(s).

The password leak is triggered if an at sign (@) is used in the password field, like this: passw@rd123. If we also consider a user dan, curl would generate a full URL like:

https://dan:passw@rd123@example.com/path

Database specific
{
    "CWE": {
        "id": "CWE-200",
        "desc": "Exposure of Sensitive Information to an Unauthorized Actor"
    },
    "award": {
        "amount": "400",
        "currency": "USD"
    },
    "URL": "https://curl.se/docs/CVE-2020-8169.json",
    "package": "curl",
    "severity": "Medium",
    "issue": "https://hackerone.com/reports/874778",
    "www": "https://curl.se/docs/CVE-2020-8169.html",
    "last_affected": "7.70.0"
}
References
Credits
    • Marek Szlagor - FINDER
    • Gregory Jefferis - FINDER
    • Jeroen Ooms - FINDER
    • Daniel Stenberg - REMEDIATION_DEVELOPER

Affected packages

Git / github.com/curl/curl.git

Affected ranges

Type
SEMVER
Events
Introduced
7.62.0
Fixed
7.71.0
Type
GIT
Repo
https://github.com/curl/curl.git
Events

Affected versions

7.*

7.62.0
7.63.0
7.64.0
7.64.1
7.65.0
7.65.1
7.65.2
7.65.3
7.66.0
7.67.0
7.68.0
7.69.0
7.69.1
7.70.0