Buffer overflow in curl and libcurl, manifested when accessing through a SOCKS5 proxy

A vulnerability (CVE-2023-38545) has been identified in the utility for receiving and sending data over the curl network and the libcurl library, which is being developed in parallel, which can lead to a buffer overflow and potentially execution of attacker code on the client side when accessed using the curl utility or an application using libcurl, to an HTTPS server controlled by the attacker. The problem only appears if access via a SOCKS5 proxy is enabled in curl. When accessing directly without a proxy, the vulnerability does not appear. The vulnerability is fixed in curl 8.4.0 release. The security researcher who discovered the bug received a $4660 reward as part of Hackerone's Internet Bug Bounty initiative.

The vulnerability is caused by an error in the hostname resolution code before accessing the SOCKS5 proxy. If the host name is up to 256 characters long, curl immediately passes the name to the SOCKS5 proxy for resolution on its side, and if the name is more than 255 characters, it switches to the local resolver and passes the already defined address to SOCKS5. Due to an error in the code, the flag indicating the need for local resolution could be set to the wrong value during the slow negotiation of a connection via SOCKS5, which led to the recording of a long host name in a buffer allocated with the expectation of storing the IP address or name , not exceeding 255 characters.

The owner of a site accessed by curl through a SOCKS5 proxy can trigger a client-side buffer overflow by returning a request redirect code (HTTP 30x) and setting the "Location:" header to a URL with a hostname in the range of 16 up to 64 KB (16 KB is the minimum size required to overflow the allocated buffer, and 65 KB is the maximum allowed hostname length in a URL). If request redirection is enabled in the libcurl settings and the SOCKS5 proxy used is slow enough, then the long host name will be written to a small buffer, obviously of a smaller size.

The vulnerability mainly affects applications based on libcurl and appears in the curl utility only when using the β€œ--limit-rate” option with a value less than 65541 - libcurl by default allocates a buffer of 16 KB in size, and in the curl utility it is 100 KB, but this the size changes depending on the value of the β€œ-limit-rate” parameter.

Daniel Stenberg, the author of the project, mentioned that the vulnerability remained undetected for 1315 days. It also says that 41% of previously identified vulnerabilities in curl could likely have been avoided if curl had been written in a memory-safe language, but there are no plans to rewrite curl into another language in the foreseeable future. As measures to improve the security of the code base, it is proposed to expand the tools for testing code and more actively use dependencies written in programming languages ​​that ensure safe operation with memory. It is also considering the possibility of gradually replacing parts of curl with options written in secure languages, such as the experimental Hyper HTTP backend implemented in Rust.

Source: opennet.ru

Add a comment