Re: [SECURITY ADVISORY] curl: overwrite local file with -J

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
Received on 2020-06-24