Hello Daniel, Thanks for sharing this CVE.
----- Original Message ----- > curl overwrite local file with -J > ================================= > > Project curl Security Advisory, June 24th 2020 - > [Permalink](https://curl.haxx.se/docs/CVE-2020-8177.html) > > VULNERABILITY > ------------- > > > 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/ > ------------------------------------------------------------------- > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
