==================================================================== CERT-Renater Note d'Information No. 2021/VULN287 _____________________________________________________________________ DATE : 27/05/2021 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running curl, libcurl versions prior to 7.77.0. ===================================================================== https://curl.se/docs/CVE-2021-22898.html https://curl.se/docs/CVE-2021-22901.html https://curl.se/docs/CVE-2021-22897.html _____________________________________________________________________ TELNET stack contents disclosure ================================ Project curl Security Advisory, May 26th 2021 - [Permalink](https://curl.se/docs/CVE-2021-22898.html) VULNERABILITY ------------- curl supports the `-t` command line option, known as `CURLOPT_TELNETOPTIONS` in libcurl. This rarely used option is used to send variable=content pairs to TELNET servers. Due to flaw in the option parser for sending `NEW_ENV` variables, libcurl could be made to pass on uninitialized data from a stack based buffer to the server. Therefore potentially revealing sensitive internal information to the server using a clear-text network protocol. This could happen because curl did not check the return code from a `sscanf(command, "%127[^,],%127s")` function invoke correctly, and would leave the piece of the send buffer uninitialized for the value part if it was provided longer than 127 bytes. The buffer used for this is 2048 bytes big and the *variable* part of the *variable=content* pairs would be stored correctly in the send buffer, making curl sending "interleaved" bytes sequences of stack contents. A single curl TELNET handshake could then be made to send off a total of around 1800 bytes of (non-contiguous) stack contents in this style: [control byte]name[control byte] stack contents [control byte]name[control byte] stack contents ... An easy proof of concept command line looks like this: curl telnet://example.com -tNEW_ENV=a,bbbbbb (256 'b's) We are not aware of any exploit of this flaw. INFO ---- This flaw has existed in curl since commit [a1d6ad2610](https://github.com/curl/curl/commit/a1d6ad2610) in libcurl 7.7, released on March 22, 2001. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2021-22898 to this issue. CWE-457: Use of Uninitialized Variable Severity: Medium AFFECTED VERSIONS ----------------- - Affected versions: curl 7.7 to and including 7.76.1 - Not affected versions: curl < 7.7 and curl >= 7.77.0 Also note that libcurl is used by many applications, and not always advertised as such. THE SOLUTION ------------ Use sscanf() properly and only use properly filled-in buffers. A [fix for CVE-2021-22898](https://github.com/curl/curl/commit/39ce47f219b09c380b81f89fe54ac586c8db6bde) RECOMMENDATIONS -------------- A - Upgrade curl to version 7.77.0 B - Apply the patch to your local version C - Avoid using `CURLOPT_TELNETOPTIONS` TIMELINE -------- This issue was reported to the curl project on April 27, 2021. This advisory was posted on May 26, 2021. CREDITS ------- This issue was reported and patched by Harry Sintonen. 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/ _____________________________________________________________________ TLS session caching disaster ============================ Project curl Security Advisory, May 26th 2021 - [Permalink](https://curl.se/docs/CVE-2021-22901.html) VULNERABILITY ------------- libcurl can be tricked into using already freed memory when a new TLS session is negotiated or a client certificate is requested on an existing connection. For example, this can happen when a TLS server requests a client certificate on a connection that was established without one. A malicious server can use this in rare unfortunate circumstances to potentially reach remote code execution in the client. OpenSSL can declare a "new session" for different reasons, including the initial TLS handshake completion, TLS 1.2 (or earlier) renegotiation, or TLS 1.3 client certificate requests. When libcurl at run-time sets up support for session ID caching on a connection using OpenSSL, it stores pointers to the transfer in-memory object for later retrieval when OpenSSL considers a new session to be established. However, if the connection is used by multiple transfers (like with a reused HTTP/1.1 connection or multiplexed HTTP/2 connection) that first transfer object might be freed before the new session is established on that connection and then the function will access a memory buffer that might be freed. When using that memory, libcurl might even call a function pointer in the object, making it possible for a remote code execution if the server could somehow manage to get crafted memory content into the correct place in memory. We are not aware of any exploit of this flaw. INFO ---- The flaw can only happen in libcurl built to use OpenSSL (or one of its forks). This flaw has existed in curl since commit [a304051620b92](https://github.com/curl/curl/commit/a304051620b92) in libcurl 7.75.0, released on February 3, 2021. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2021-22901 to this issue. CWE-416: Use After Free Severity: High ## Steps to remote code execution 1. libcurl built to use OpenSSL (BoringSSL and libressl work the same) 2. A multi interface using application 3. One of the following: - create and use a first easy handle to do HTTP/1.1 over TLS to a malicious server - free that easy handle with `curl_easy_cleanup()` - create and use a second easy handle to do HTTP/1.1 over TLS with to the same server such that the TLS connection is reused or - more than one concurrent easy handle created that do HTTP/2 over a TLS connection to a malicious server, - the *first* easy handle to use the connection must be freed with `curl_easy_cleanup()` - at least one easy handle remaining in use of the same connection 4. The attacking server needs to figure out heap address details in order to know what payload contents to provide 5. The necessary exact memory address in the heap gets populated by memory contents controlled by the server 6. The attacker starts a new handshake (on TLS 1.2 or earlier), or sends a TLS 1.3 client certificate request, or otherwise triggers OpenSSL to consider a new session to be established For a remote code execution, the client needs to perform (potentially many) more transfers (and thus have more easy handles) to allow the server to place crafted contents into heap memory. Instead of remote code execution, the client could instead crash or otherwise experience undefined behaviour. AFFECTED VERSIONS ----------------- - Affected versions: curl 7.75.0 to and including 7.76.1 - Not affected versions: curl < 7.75.0 and curl >= 7.77.0 Also note that libcurl is used by many applications, and not always advertised as such. THE SOLUTION ------------ When the transfer is detached from the connection, it clears the association to it from the session ID cache logic. A [fix for CVE-2021-22901](https://github.com/curl/curl/commit/7f4a9a9b2a49547eae24d2e19bc5c346e9026479) RECOMMENDATIONS -------------- A - Upgrade curl to version 7.77.0 B - Apply the patch to your local version C - Build libcurl to use another TLS backend TIMELINE -------- This issue was reported to the curl project on April 29, 2021. This advisory was posted on May 26, 2021. CREDITS ------- This issue was reported by Harry Sintonen. Patched by Harry Sintonen and Daniel Stenberg. Help and research by Brad Spencer. 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/ _____________________________________________________________________ schannel cipher selection surprise Project curl Security Advisory, May 26th 2021 VULNERABILITY libcurl lets applictions specify which specific TLS ciphers to use in transfers, using the option called CURLOPT_SSL_CIPHER_LIST. The cipher selection is used for the TLS negotation when a transfer is done involving any of the TLS based transfer protocols libcurl supports, such as HTTPS, FTPS, IMAPS, POP3S, SMTPS etc. Due to a mistake in the code, the selected cipher set was stored in a single "static" variable in the library, which has the surprising side-effect that if an application sets up multiple concurrent transfers, the last one that sets the ciphers will accidentally control the set used by all transfers. In a worst-case scenario, this weakens transport security significantly. We are not aware of any exploit of this flaw. INFO This flaw has existed in libcurl since commit 9aefbff30d280c60fc in libcurl 7.61.0, released on July 11, 2018. It can only trigger when Schannel is used, which is the native TLS library in Microsoft Windows. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2021-22897 to this issue. CWE-488: Exposure of Data Element to Wrong Session Severity: Low AFFECTED VERSIONS This issue only exists when libcurl is built to use Schannel. Affected versions: libcurl 7.61.0 to and including 7.76.1 Not affected versions: libcurl < 7.61.0 and libcurl >= 7.77.0 Also note that libcurl is used by many applications, and not always advertised as such. THE SOLUTION Store the cipher selection in data associated with the connection. A fix for CVE-2021-22897 RECOMMENDATIONS If you're using an Schannel based libcurl, We suggest you take one of the following actions immediately, in order of preference: A - Upgrade libcurl to version 7.77.0 B - Apply the patch to your local version C - Avoid using CURLOPT_SSL_CIPHER_LIST TIMELINE This issue was reported to the curl project on April 23, 2021. This advisory was posted on May 26, 2021. CREDITS This issue was reported by Harry Sintonen. Patch by Daniel Stenberg. Thanks a lot! ========================================================= + 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 + =========================================================