Bug 1847915 (CVE-2020-8177) - CVE-2020-8177 curl: Incorrect argument check can allow remote servers to overwrite local files
Summary: CVE-2020-8177 curl: Incorrect argument check can allow remote servers to over...
Keywords:
Status: NEW
Alias: CVE-2020-8177
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1851430 1851432 1851426 1851427 1851428 1851429 1851433
Blocks: 1847917
TreeView+ depends on / blocked
 
Reported: 2020-06-17 10:45 UTC by msiddiqu
Modified: 2020-08-14 19:00 UTC (History)
39 users (show)

Fixed In Version: curl 7.71.0
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in curl. Overwriting local files is possible when using a certain combination of command line options. Requesting content from a malicious server could lead to overwriting local files with compromised files leading to unknown effects. The highest threat from this vulnerability is to file integrity.
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
vendor patch slightly edited for 7.29.0-57 (1.13 KB, patch)
2020-07-23 11:35 UTC, Scott Nicholas
no flags Details | Diff

Description msiddiqu 2020-06-17 10:45:33 UTC
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.

Comment 5 Stefan Cornelius 2020-06-26 13:46:28 UTC
External References:

https://curl.haxx.se/docs/CVE-2020-8177.html

Comment 6 Stefan Cornelius 2020-06-26 13:48:49 UTC
Created curl tracking bugs for this issue:

Affects: fedora-all [bug 1851426]


Created flickcurl tracking bugs for this issue:

Affects: epel-7 [bug 1851429]
Affects: fedora-all [bug 1851428]


Created mingw-curl tracking bugs for this issue:

Affects: fedora-all [bug 1851427]

Comment 10 Scott Nicholas 2020-07-23 11:35:48 UTC
Created attachment 1702219 [details]
vendor patch slightly edited for 7.29.0-57

would like this fixed asap for rhel7. here is proposed patch

Comment 11 Credog 2020-07-23 16:23:10 UTC
Yes, please fix ASAP on RHEL7. Important to our organization.  Removing curl not really an option.

Comment 12 John Haxby 2020-07-24 12:53:04 UTC
From https://curl.haxx.se/docs/CVE-2020-8177.html:

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

To me, that suggests the sky isn't falling because you have to use "-J -i" (in that order) along with -O.  If you're not using "-J" or not using "-i" or using "-i" before "-J" then you're not vulnerable.

Comment 13 Scott Nicholas 2020-07-24 13:01:16 UTC
(In reply to John Haxby from comment #12)
> To me, that suggests the sky isn't falling because you have to use "-J -i"
> (in that order) along with -O.  If you're not using "-J" or not using "-i"
> or using "-i" before "-J" then you're not vulnerable.

I agree... but it's on Tenable Nessus scans and my organization issued a vulnerability message about it and therefore requires a lot of paperwork nonsense every few months if it isn't patched.

Tenable's recommended fix is to apply curl-7.71.0-el7 which doesn't exist. If this gets fixed in curl-7.29.0-58 then we can have them update their plugin and all is well.

Comment 14 Kamil Dudka 2020-07-24 13:59:06 UTC
(In reply to John Haxby from comment #12)
> To me, that suggests the sky isn't falling because you have to use "-J -i"
> (in that order) along with -O.

Who says that you have to use "-J -i" ?

Why would anyone use such a combination of options in the first place?

(In reply to Scott Nicholas from comment #13)
> I agree... but it's on Tenable Nessus scans

Any idea how exactly this CVE got there?

There are many similar CVEs that have not been fixed in RHEL-7 curl.

Comment 15 Scott Nicholas 2020-07-24 14:09:33 UTC
(In reply to Kamil Dudka from comment #14)
> Any idea how exactly this CVE got there?

Likely because it was assigned an IAVA: 2020-A-0291 by USCYBERCOM - reference <https://www.tenable.com/plugins/nessus/138374>.

I couldn't say why it gets such treatment and the others you mentioned do not.

Comment 16 Credog 2020-07-24 15:33:19 UTC
Same as Scott.  We have in Tenable and have to handle the vulnerability in some fashion.  Just telling people to not use "-J -i" is not going to fly in my organization.

Comment 17 Kamil Dudka 2020-07-24 15:35:24 UTC
Thanks for the reference!  I think that explains all the fuss around this CVE:

    "An authenticated, local attacker can exploit this, via use of a malicious server to trick curl to overwrite files on the remote host."

Seriously, an authenticated local attacker who can control curl options can just use -o /file/to/overwrite without needing any malicious server.  The fix for this CVE is not going to change this.

Comment 21 Chuck Milam 2020-07-27 15:28:38 UTC
Same as some commenters above, we are part of an organization that is required to act on CYBERCOM IAVAs, and uninstalling curl is not an option for us.  Not sure what Red Hat's package update policy is, but I'd personally like to see curl updated to the currently-supported release version rather than patched, as Nessus scans may not differentiate between a patched vs. an updated version.

Comment 22 Michael Cronenworth 2020-07-27 15:51:58 UTC
Nessus will be aware of the patched RHEL package when it is released. There is no need to panic or uninstall curl.

The best method to expedite a patched package is through your Red Hat account or support representative and not this bug report.

Comment 23 John Haxby 2020-07-27 15:56:29 UTC
I think there's an issue with the advisory.  Comment #17 and the advisory both say "... overwrite remote files" when I believe it should say "... overwrite local files".   The curl advisory, however, talks about overwriting local files which is completely different, plausible and nowhere near as serious.

Comment 24 Kamil Dudka 2020-07-27 16:23:12 UTC
The quoted text in comment #17 you refer to is a citation from https://www.tenable.com/plugins/nessus/138374 which I disagree with.

I believe that the advisory released by curl upstream (mentioned in comment #5) is accurate though.

Comment 25 Stefan Cornelius 2020-07-27 20:01:56 UTC
Statement:

This issue only affects the 'curl' command line utility. Additionally, this is only an issue when using the '-J' (with the '-O' option) and '-i' command line options combined.

In most cases, there is nothing to gain for a local attacker here: the curl command line utility is likely running with the same privileges as the user, and thus the user can already overwrite all the files curl could overwrite. However, a local user will have to call curl with the '-J' and '-i' command line options while requesting content from a malicious server, which then opens up an opportunity for the malicious server to overwrite local files.

Comment 29 KT 2020-07-31 22:36:26 UTC
Hi, 
when will redhat come out with a updated version?

Comment 31 Eric Christensen 2020-08-03 14:11:14 UTC
Mitigation:

The vulnerability is only possible when using the '-J' and '-i' switches in conjunction with the curl command.  Executing curl without these switches mitigates the flaw.

Comment 34 Yogendra Jog 2020-08-05 06:46:52 UTC
In reply to comment #29:
> Hi, 
> when will redhat come out with a updated version?

I recommend you to open a support case and ask support to prioritize the fix for specific RHEL release you are using.

Regards
Yogendra.

Comment 36 Credog 2020-08-11 16:32:36 UTC
It looks like a new curl package (curl-7.29.0-57.el7_8.1.x86_64) was available and installed on 8/7. The last change log entry for the package was for Jun 02 2020.  Anyone have any insight if this fixed the -J and -i issue?

Comment 37 Scott Nicholas 2020-08-11 18:05:38 UTC
(In reply to Credog from comment #36)
> It looks like a new curl package (curl-7.29.0-57.el7_8.1.x86_64) was
> available and installed on 8/7. The last change log entry for the package
> was for Jun 02 2020.  Anyone have any insight if this fixed the -J and -i
> issue?

no. ``yum changelog'' doesn't seem to mention anything but RHBA-2020:3348 (BZ#1844432) mentioned this update.


Note You need to log in before you can comment on or make changes to this bug.