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.
External References: https://curl.haxx.se/docs/CVE-2020-8177.html
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]
Created attachment 1702219 [details] vendor patch slightly edited for 7.29.0-57 would like this fixed asap for rhel7. here is proposed patch
Yes, please fix ASAP on RHEL7. Important to our organization. Removing curl not really an option.
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.
(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.
(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.
(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.
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.
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.
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.
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.
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.
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.
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.
Hi, when will redhat come out with a updated version?
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.
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.
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?
(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.
curl-7.29.0-59.el7_9.1 contains the fix for CVE-2020-8177 but it has not yet been released. If you need an accelerated fix, please contact Product Support.
Hello Kamil, When are we planning to release curl-7.29.0-59.el7_9.1 ?
It is currently planned to be released in a z-stream update after RHEL-7.9 GA. Please escalate it via GSS if you need the fix any sooner.
Is there any update on this ? Tenable scanners are complaining about this on RHEL while Centos seems to be fine. It expects the curl-7.29.0-59.el7_9.1.
(In reply to yaro014 from comment #47) > Is there any update on this? See comment #40. > Tenable scanners are complaining about this on > RHEL while Centos seems to be fine. I do not think this has already been fixed in CentOS. > It expects the curl-7.29.0-59.el7_9.1. Yes, the above build contains the fix.
7.9 is out, assume we are still waiting on the z-stream update? Any updates on timeframe? Looks like an update was done on 9/30, but the CVE didn't appear to be included. Thanks
The 7.9 GA update did not include the fix for CVE-2020-8177. The fix is going to be included in the first z-stream batch.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:4599 https://access.redhat.com/errata/RHSA-2020:4599
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-8177
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:5002 https://access.redhat.com/errata/RHSA-2020:5002
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Extended Update Support Via RHSA-2020:5417 https://access.redhat.com/errata/RHSA-2020:5417