==================================================================== CERT-Renater Note d'Information No. 2020/VULN669 _____________________________________________________________________ DATE : 09/12/2020 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running curl versions prior to 7.74.0. ===================================================================== https://curl.se/docs/CVE-2020-8284.html https://curl.se/docs/CVE-2020-8285.html https://curl.se/docs/CVE-2020-8286.html _____________________________________________________________________ trusting FTP PASV responses =========================== Project curl Security Advisory, December 9th 2020 - [Permalink](https://curl.se/docs/CVE-2020-8284.html) VULNERABILITY ------------- When curl performs a passive FTP transfer, it first tries the `EPSV` command and if that is not supported, it falls back to using `PASV`. Passive mode is what curl uses by default. A server response to a `PASV` command includes the (IPv4) address and port number for the client to connect back to in order to perform the actual data transfer. This is how the FTP protocol is designed to work. A malicious server can use the `PASV` response to trick curl into connecting back to a given IP address and port, and this way potentially make curl extract information about services that are otherwise private and not disclosed, for example doing port scanning and service banner extractions. If curl operates on a URL provided by a user (which by all means is an unwise setup), a user can exploit that and pass in a URL to a malicious FTP server instance without needing any server breach to perform the attack. We are not aware of any exploit of this flaw. INFO ---- This issue has existed in curl for as long as FTP has been supported, since day 1. The flaw only exists for IPv4 since `PASV` doesn't work for IPv6 and curl will prefer `EPSV`. The passive mode setup for FTP is used for both uploads and downloads. curl can be built without FTP support and applications can explicitly disable FTP for single transfers. curl users could already mitigate this flaw with `CURLOPT_FTP_SKIP_PASV_IP` and `--ftp-skip-pasv-ip`. Other FTP clients have in the past also had this flaw and have fixed it at different points in time. Firefox fixed it in 2007: CVE-2007-1562. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2020-8284 to this issue. CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Severity: Low AFFECTED VERSIONS ----------------- - Affected versions: curl 4.0 to and including 7.73.0 - Not affected versions: curl >= 7.74.0 Also note that (lib)curl is used by many applications, and not always advertised as such. THE SOLUTION ------------ The IP address part of the response is now ignored by default, by making `CURLOPT_FTP_SKIP_PASV_IP` default to `1L` instead of previously being `0L`. This has the minor drawback that a small fraction of use cases might break, when a server truly needs the client to connect back to a different IP address than what the control connection uses and for those `CURLOPT_FTP_SKIP_PASV_IP` can be set to `0L`. The same goes for the command line tool, which then might need `--no-ftp-skip-pasv-ip` set to prevent curl from ignoring the address in the server response. A [fix for CVE-2020-8284](https://github.com/curl/curl/commit/ec9cc725d598ac) RECOMMENDATIONS -------------- We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl to version 7.74.0 B - Set `CURLOPT_FTP_SKIP_PASV_IP` to `1L` or use `--ftp-skip-pasv-ip` C - Disable FTP availability for your transfers TIMELINE -------- This issue was first reported to the curl project on November 21, 2020. This advisory was posted on December 9th 2020. CREDITS ------- This issue was reported by Varnavas Papaioannou. 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/ _____________________________________________________________________ FTP wildcard stack overflow =========================== Project curl Security Advisory, December 9th 2020 - [Permalink](https://curl.se/docs/CVE-2020-8285.html) VULNERABILITY ------------- libcurl offers a wildcard matching functionality, which allows a callback (set with `CURLOPT_CHUNK_BGN_FUNCTION`) to return information back to libcurl on how to handle a specific entry in a directory when libcurl iterates over a list of all available entries. When this callback returns `CURL_CHUNK_BGN_FUNC_SKIP`, to tell libcurl to not deal with that file, the internal function in libcurl then calls itself recursively to handle the next directory entry. If there's a sufficient amount of file entries and if the callback returns "skip" enough number of times, libcurl runs out of stack space. The exact amount will of course vary with platforms, compilers and other environmental factors. The content of the remote directory is not kept on the stack, so it seems hard for the attacker to control exactly what data that overwrites the stack - however it remains a Denial-Of-Service vector as a malicious user who controls a server that a libcurl-using application works with under these premises can trigger a crash. (There is also a few other ways the function can be made to call itself and trigger this problem.) We are not aware of any exploit of this flaw. INFO ---- This issue was unfortunately reported publicly in the curl GitHub issue tracker as [issue 6255](https://github.com/curl/curl/issues/6255). This flaw has existed in curl since commit [0825cd80a](https://github.com/curl/curl/commit/0825cd80a) in curl 7.21.0. This functionality is not used by the curl tool so it is not affected. Further: it is not a very widely used feature. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2020-8285 to this issue. CWE-674: Uncontrolled Recursion Severity: Medium AFFECTED VERSIONS ----------------- - Affected versions: libcurl 7.21.0 to and including 7.73.0 - Not affected versions: libcurl < 7.21.0 and libcurl >= 7.74.0 Also note that libcurl is used by many applications, and not always advertised as such. THE SOLUTION ------------ The internal function is rewritten to instead and more appropriately use an ordinary loop instead of the recursive approach. This way, the stack use will remain the same no matter how many files that are skipped. A [fix for CVE-2020-8285](https://github.com/curl/curl/commit/69a358f2186e04) RECOMMENDATIONS -------------- We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl to version 7.74.0 B - Disable FTP wildcard use (`CURLOPT_WILDCARDMATCH`) C - Make sure your `CURLOPT_CHUNK_BGN_FUNCTION` callback doesn't do multiple skips. TIMELINE -------- This issue was first reported to the curl project on November 27, 2020. This advisory was posted on December 9th 2020. CREDITS ------- This issue was initially reported by xnynx on GitHub. Daniel took it to the security team immediately. Patch 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/ _____________________________________________________________________ Inferior OCSP verification ========================== Project curl Security Advisory, December 9th 2020 - [Permalink](https://curl.se/docs/CVE-2020-8286.html) VULNERABILITY ------------- libcurl offers "OCSP stapling" via the `CURLOPT_SSL_VERIFYSTATUS` option. When set, libcurl verifies the OCSP response that a server responds with as part of the TLS handshake. It then aborts the TLS negotiation if something is wrong with the response. The same feature can be enabled with `--cert-status` using the curl tool. As part of the OCSP response verification, a client should verify that the response is indeed set out for the correct certificate. This step was not performed by libcurl when built or told to use OpenSSL as TLS backend. This flaw would allow an attacker, who perhaps could have breached a TLS server, to provide a fraudulent OCSP response that would appear fine, instead of the real one. Like if the original certificate actually has been revoked. We are not aware of any exploit of this flaw. INFO ---- This flaw has existed in curl since commit [d1cf5d570663d](https://github.com/curl/curl/commit/d1cf5d570663d) in curl 7.41.0. The vulnerability is present only if OpenSSL is the designated TLS backend. OCSP stapling is not enabled by default by libcurl, it needs to be explicitly enabled by the application to get used. OCSP Stapling can be used with any of the TLS based protocols curl supports, including HTTPS, FTPS, SMTPS, POP3S, IMAPS, HTTPS-proxy and more. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2020-8286 to this issue. CWE-299: Improper Check for Certificate Revocation Severity: Medium AFFECTED VERSIONS ----------------- - Affected versions: libcurl 7.41.0 to and including 7.73.0 - Not affected versions: libcurl < 7.41.0 and libcurl >= 7.74.0 Also note that libcurl is used by many applications, and not always advertised as such. THE SOLUTION ------------ The OCSP response checker function now also verifies that the certificate id is the correct one. A [fix for CVE-2020-8286](https://github.com/curl/curl/commit/d9d01672785b) RECOMMENDATIONS -------------- We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl to version 7.74.0 B - Don't rely on OCSP TIMELINE -------- This issue was first reported to the curl project on December 2, 2020. This advisory was posted on December 9th 2020. CREDITS ------- This issue was identified and patched by an Ospoco customer who wishes to remain anonymous. Reported by Ospoco (https://ospo.co). 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 + =========================================================