TELNET stack contents disclosure
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)
02 / AFFECTED SOFTWARE
Affected packages
171 explicit affected versions
312 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
curl 7.7 through 7.76.1 suffers from an information disclosure when the `-t` command line option, known as `CURLOPT_TELNETOPTIONS` in libcurl, is used to send variable=content pairs to TELNET servers. Due to a 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, resulting in potentially revealing sensitive internal information to the server using a clear-text network protocol.
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)
05 / REFERENCES
Further evidence
- http://www.openwall.com/lists/oss-security/2021/07/21/4
- https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf
- https://curl.se/docs/CVE-2021-22898.html
- https://github.com/curl/curl/commit/39ce47f219b09c380b81f89fe54ac586c8db6bde
- https://hackerone.com/reports/1176461
- https://lists.apache.org/thread.html/rc713534b10f9daeee2e0990239fa407e2118e4aa9e88a7041177497c%40%3Cissues.guacamole.apache.org%3E
- https://lists.debian.org/debian-lts-announce/2021/08/msg00017.html
- https://lists.debian.org/debian-lts-announce/2022/08/msg00017.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FRUCW2UVNYUDZF72DQLFQR4PJEC6CF7V/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/POOC3UV7V6L4CJ5KA2PTWTNUV5Y72T3Q/
- https://www.debian.org/security/2022/dsa-5197
- https://www.oracle.com//security-alerts/cpujul2021.html
- https://www.oracle.com/security-alerts/cpuapr2022.html
- https://www.oracle.com/security-alerts/cpujan2022.html