wrong connect-only connection
An application that performs multiple requests with libcurl's multi API and sets the `CURLOPT_CONNECT_ONLY` option, might in rare circumstances experience that when subsequently using the setup connect-only transfer, libcurl picks and uses the wrong connection - and instead picks another one the application has created since then. `CURLOPT_CONNECT_ONLY` is the option to tell libcurl to not perform an actual transfer, only connect. When that operation is completed, libcurl remembers which connection it used for that transfer and "easy handle". It remembers the connection using a pointer to the internal `connectdata` struct in memory. If more transfers are then done with the same multi handle before the connect-only connection is used, leading to the initial connect-only connection to get closed (for example due to idle time-out) while also new transfers (and connections) are setup, such a *new* connection might end up getting the exact same memory address as the now closed connect-only connection. If after those operations, the application then wants to use the original transfer's connect-only setup to for example use `curl_easy_send()` to send raw data over that connection, libcurl could **erroneously** find an existing connection still being alive at the address it remembered since before even though this is now a new and different connection. The application could then accidentally send data over that connection which was not at all intended for that recipient, entirely unknowingly.
02 / AFFECTED SOFTWARE
Affected packages
61 explicit affected versions
124 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
Due to use of a dangling pointer, libcurl 7.29.0 through 7.71.1 can use the wrong connection when sending data.
An application that performs multiple requests with libcurl's multi API and sets the `CURLOPT_CONNECT_ONLY` option, might in rare circumstances experience that when subsequently using the setup connect-only transfer, libcurl picks and uses the wrong connection - and instead picks another one the application has created since then. `CURLOPT_CONNECT_ONLY` is the option to tell libcurl to not perform an actual transfer, only connect. When that operation is completed, libcurl remembers which connection it used for that transfer and "easy handle". It remembers the connection using a pointer to the internal `connectdata` struct in memory. If more transfers are then done with the same multi handle before the connect-only connection is used, leading to the initial connect-only connection to get closed (for example due to idle time-out) while also new transfers (and connections) are setup, such a *new* connection might end up getting the exact same memory address as the now closed connect-only connection. If after those operations, the application then wants to use the original transfer's connect-only setup to for example use `curl_easy_send()` to send raw data over that connection, libcurl could **erroneously** find an existing connection still being alive at the address it remembered since before even though this is now a new and different connection. The application could then accidentally send data over that connection which was not at all intended for that recipient, entirely unknowingly.
05 / REFERENCES
Further evidence
- https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf
- https://curl.haxx.se/docs/CVE-2020-8231.html
- https://hackerone.com/reports/948876
- https://lists.apache.org/thread.html/r58af02e294bd07f487e2c64ffc0a29b837db5600e33b6e698b9d696b%40%3Cissues.bookkeeper.apache.org%3E
- https://lists.apache.org/thread.html/rf4c02775860db415b4955778a131c2795223f61cb8c6a450893651e4%40%3Cissues.bookkeeper.apache.org%3E
- https://security.gentoo.org/glsa/202012-14
- https://www.debian.org/security/2021/dsa-4881
- https://www.oracle.com/security-alerts/cpuapr2022.html