==================================================================== CERT-Renater Note d'Information No. 2020/VULN357 _____________________________________________________________________ DATE : 24/06/2020 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running curl versions 7.20.0 up to and including 7.70.0. ===================================================================== https://curl.haxx.se/docs/CVE-2020-8169.html https://curl.haxx.se/docs/CVE-2020-8177.html _____________________________________________________________________ Partial password leak over DNS on HTTP redirect =============================================== Project curl Security Advisory, June 24th 2020 - [Permalink](https://curl.haxx.se/docs/CVE-2020-8169.html) VULNERABILITY ------------- 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). 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` ... while a correct one should have been: `https://dan:passw%40rd123 () example com/path` ... when parsing the wrongly generated URL, libcurl would end up with user name `dan` and password `passw` talking to the host `rd123 () example com`. That bad host name would then be passed on to the name resolver function in use (and for all typical cases return a "cannot resolve host name" error). There's no hint in the name resolve as to how large portion of the password that is actually prepended to the host name (ie an observer won't know how much data there was on the left side of the `@`), but it can of course be a significant enough clue for an attacker to figure out the rest. We are not aware of any exploit of this flaw. INFO ---- Requirements to trigger this flaw. 1. a password set with a `@` in it 2. an HTTP transfer 3. a *relative* redirect that curl follows (`CURLOPT_FOLLOWLOCATION` enabled) This bug was brought in commit [46e164069d](https://github.com/curl/curl/commit/46e164069d), first shipped in curl 7.62.0. This flaw can happen to users of the curl tool as well as for applications using libcurl. This bug was reported and inadvertently fixed and pushed to the public source respository before anyone realized its security impact. The effects of this flaw is somewhat reduced if DNS-over-HTTPS is used, since then at least the name won't be observable on the network by a passive by-stander but only by the DoH server. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2020-8169 to this issue. CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Severity: 5.5 (Medium) AFFECTED VERSIONS ----------------- - Affected versions: libcurl 7.62.0 to and including 7.70.0 - Not affected versions: libcurl < 7.62.0 libcurl is used by many applications, but not always advertised as such. THE SOLUTION ------------ A [fix for CVE-2020-8169](https://github.com/curl/curl/commit/600a8cded447cd) RECOMMENDATIONS -------------- We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl to version 7.71.0 B - Apply the patch on your libcurl version and rebuild C - Disable `CURLOPT_FOLLOWLOCATION` or redirects to HTTP(S). TIMELINE -------- This issue was first reported to the curl project on May 14, 2020. The initial fix was done, verified and pushed to git on the same day. (As a regular non-security related fix.) On May 15, 2020, the bug was reported again but then with the security impact highlighted. This advisory was posted on June 24th 2020. CREDITS ------- The security issue was reported by Marek Szlagor. The initial bug report was done by Gregory Jefferis and Jeroen Ooms. Patched by Daniel Stenberg. Thanks a lot! / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ _____________________________________________________________________ curl overwrite local file with -J ================================= Project curl Security Advisory, June 24th 2020 - [Permalink](https://curl.haxx.se/docs/CVE-2020-8177.html) VULNERABILITY ------------- curl can be tricked my a malicious server to overwrite a local file when using `-J` (`--remote-header-name`) and `-i` (`--head`) 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.) We are not aware of any exploit of this flaw. INFO ---- Users should be aware and *never* run curl with the `-J` option in their `$HOME` or other sensitive directories, independently of this flaw. Using curl that way allows curl to create any file name it likes (i.e. what the remote server suggests) and it can confuse or trick users if allowed to save files that can mistakenly be assumed to be "locally made" or part of the system rather than provided by a potentially malicious remote party. This bug was brought in commit [80675818e0417b](https://github.com/curl/curl/commit/80675818e0417b) when `-J` was introduced to curl, first shipped in curl 7.20.0. This flaw can happen to users of the curl tool but **not** for applications using libcurl. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2020-8177 to this issue. CWE-641: Improper Restriction of Names for Files and Other Resources Severity: 4.7 (Medium) AFFECTED VERSIONS ----------------- - Affected versions: curl 7.20.0 to and including 7.70.0 - Not affected versions: curl < 7.20.0 and curl >= 7.71.0 THE SOLUTION ------------ A [fix for CVE-2020-8177](https://github.com/curl/curl/commit/8236aba58542c5f.patch) RECOMMENDATIONS -------------- We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl to version 7.71.0 B - Apply the patch on your curl version and rebuild C - Do not use `-J` (in a directory with pre-existing files) TIMELINE -------- This issue was first reported to the curl project on May 30, 2020. This advisory was posted on June 24th 2020. CREDITS ------- This issue was reported by sn on hackerone. Patched by Daniel Stenberg. Thanks a lot! / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================