Buffer overflow in curl and libcurl occurring when connecting through a SOCKS5 proxy

A vulnerability (CVE-2023-38545) has been identified in the data transfer utility curl and its concurrently developing library libcurl, which may lead to a buffer overflow and potentially the execution of attacker code on the client side when using curl or an application that utilizes libcurl to access an HTTPS server controlled by a malicious entity. This issue only manifests when enabling SOCKS5 proxy access in curl. The vulnerability does not appear with direct access without a proxy. It has been resolved in curl version 8.4.0. The security researcher who discovered the flaw received a reward of $4660 as part of the Internet Bug Bounty initiative on Hackerone.

The vulnerability is caused by a mistake in the hostname resolution code before connecting to the SOCKS5 proxy. For hostname lengths up to 256 characters, curl immediately sends the hostname to the SOCKS5 proxy for resolution on its side, but if the hostname exceeds 255 characters, it falls back to the local resolver and sends the already resolved address to the SOCKS5 proxy. Due to an error in the code, the flag indicating the necessity for local resolution during the slow connection handshake through SOCKS5 might have been set incorrectly, leading to the long hostname being written into a buffer allocated with a calculation for storage. an IP address or a name not exceeding 255 characters.

The owner of the site to which curl connects through the SOCKS5 proxy can initiate a buffer overflow on the client side by returning an HTTP redirect code (HTTP 30x) and setting a URL in the "Location:" header with a hostname size ranging from 16 to 64 KB (the 16 KB value is due to the minimum size required to overflow the allocated buffer, while the 65 KB value is related to the maximum allowed hostname length in a URL). If request redirection is enabled in libcurl settings and the used SOCKS5 proxy is slow enough, the long hostname will be written into a small buffer that is deliberately smaller.

The vulnerability primarily affects applications based on libcurl and manifests in the curl utility only when using the '--limit-rate' option with a value less than 65541 — libcurl by default allocates a buffer size of 16 KB, while in curl it's 100 KB, but this size varies depending on the '—limit-rate' parameter value.

Daniel Stenberg, the project's author, mentioned that the vulnerability went unnoticed for 1315 days. It was also noted that 41% of previously identified vulnerabilities in curl could likely have been avoided if curl were written in a language that ensures safe memory handling, but there are no plans to rewrite curl in another language in the foreseeable future. As safety measures for the codebase, it is suggested to expand the testing tools and more actively use dependencies written in programming languages that provide safe memory handling. There is also a consideration for a gradual replacement of parts of curl with options written in safe languages, such as the experimental HTTP backend Hyper, implemented in Rust.

Source: opennet.ru

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster