New Vulnerability in curl and libcurl Could Lead to Heap Buffer Overflow

The new high severity vulnerability in curl and libcurl

In short, this newly discovered vulnerability in the immensely popular open-source project curl may allow, under certain conditions, to cause a heap buffer overflow in the client side. A heap buffer overflow means that data is written outside the bounds of dynamically allocated memory (on the heap) due to insufficient boundary checks. This in turn can lead to denial of service, data corruption, arbitrary code execution, privilege escalation, bypass of security controls. This vulnerability was present in curl for over three years before being identified and fixed.

Affected versions:

• Affected versions: libcurl 7.69.0 to and including 8.3.0
• Not affected versions: libcurl < 7.69.0 and >= 8.4.0
• Introduced-in: https://github.com/curl/curl/commit/4a4b63daaa 

Much like log4j, ‘libcurl’ is used by many applications, but not always advertised as such.

A technical deep dive to the vulnerability

CVE-2023-38545 depends on using SOCKS5, which is a proxy protocol often used to access the internet within organizations or in anonymized internet such as The Onion Router (TOR).
When sending a curl request to SOCKS5 it will need to resolve the hostname and “translate” it via DNS to an IP address. This DNS request could happen either locally (on the requesting server) or on remote (the SOCKS5 server).

Figure 1: code snippets in curl which contain the 255 bytes inspection

If the hostname is detected to be longer than 255 bytes, curl switches to local name resolving and instead passes on the resolved address only to the proxy. Due to a bug, the local variable that means “let the host resolve the name” could get the wrong value during a SOCKS5 handshake, and contrary to the intention, copy the too long hostname to the target buffer instead of copying just the resolved address there. This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake.

A possible exploitation of this vulnerability

As depicted in figure 2 below, if a threat actor has control over an HTTPS server that receives a request from a curl client using the vulnerable ‘libcurl’ over a SOCKS5 proxy (using the proxy-resolver-mode) it can generate and return a crafted redirect to the client via a HTTP 30x response.

Figure 2: CVE-2023-38545 possible exploitation flow

The “30x redirection” would then contain a Location, where the hostname is longer than 16kB and up to 64kB. For example, lets us create a malicious server using Perl (the code is taken from the HackerOne report):

Figure 3: a mock Perl code on the attacker’s controlled HTTPS server

So, if a victim is using the vulnerable ‘libcurl’ version, has the automatic redirect-following enabled running the following curl command (‘socks-server’ refer to his SOCKS5 proxy IP address, and the ‘attacker-IP’ refer to the IP address controlled by an attacker that appears in the snippet in figure 3 above):

Figure 4: an example to a curl request by a victim via SOCKS5 proxy  

The crafted hostname will be copied into the buffer, which has a too small buffer allocated, and into the adjacent heap memory. Subsequentally a heap buffer overflow has occurred.

Dependencies for Successful Exploitation:

• Sending a request to an HTTPS server controlled by an attacker. This is a plausible scenario of an attacker having control over a server that the curl client will send a request.
• Attacker redirects a response. The attacker’s server should be able to send a redirect response (HTTP 30x) to the curl client. This redirect would point to a maliciously crafted long hostname.
• Automatic Redirect Following: The curl client should have the feature to automatically follow redirects enabled. If it’s off, the client won’t follow the malicious redirect, and the overflow won’t occur.
• Crafted Hostname: The attacker needs to craft a hostname that’s not only long enough to cause the overflow but also contains specific byte values that won’t be rejected by curl or any Internationalized Domain Name (IDN) library it might be using.

In summary, the vulnerability lies in how curl handles long hostnames when connecting via a SOCKS5 proxy. For an attacker to exploit this, they need to control a server, use it to send a malicious redirect to a curl client, and rely on specific conditions in the client’s configuration and the behavior of the SOCKS5 proxy.

Possible impact

We assume that in one scenario of exploitation of this vulnerability when the resolution is made locally, it could lead to a privacy violation. A local DNS query could possibly deanonymize a user who specifically requests SOCKS5.

In a second scenario, when the resolution is made remotely with a malformed SOCKS packet. The threat actor has written to the heap and likely overwritten in-use data that come after data->state.buffer.

It’s undefined behavior at best and possible RCE at worst. The full list of implications of Heap Overflow:

1. Data Corruption: Overflowing the buffer can corrupt data in adjacent memory locations, leading to unpredictable program behavior.
2. Denial of Service: The program can crash if critical data structures are corrupted due to the overflow.
3. Arbitrary Code Execution: A skilled attacker can exploit a heap overflow vulnerability to run arbitrary code. By carefully crafting the overflow, an attacker can overwrite function pointers or other critical data structures on the heap, redirecting the program’s execution flow to their malicious code.
4. Privilege Escalation: If a vulnerable program runs with elevated privileges, exploiting it can grant the attacker those same privileges, allowing them to perform unauthorized actions on the system.
5. Bypassing Security Mechanisms: Modern operating systems implement various security mechanisms, such as ASLR (Address Space Layout Randomization) and DEP/NX (Data Execution Prevention/No Execute). However, certain heap overflow techniques, combined with other exploits, can bypass these protections.

Detection and remediation with Aqua’s CNAPP

Figure 5: detection of the vulnerability by the Aqua platform

Utilizing Aqua’s cloud native application protection platform (CNAPP) you can both detect this vulnerability and prioritize it across your running workloads and further environments (VMs).

The platform takes a proactive approach by showing the Software Bill of Materials (SBOM), detecting the relevant CVE, establishing network connectivity and dependencies and prioritizing this vulnerability in comparison to other vulnerabilities and the various environments, leading to prioritization of the workload to remediate this vulnerability, ensuring that development teams can focus on the most impactful remediation efforts.

Figure 6: scan result of a non-vulnerable version

Below are the actionable recommendations that can be taken to ensure your impacted environments safety:

1. Upgrade curl to version 8.4.0, curl will no longer switch to local resolve mode if the name is too long but is instead rightfully returning an error.
   • Fixed version
   • Patch collection for older versions
2. Apply the patch to your local version
3. If possible, avoid using CURLPROXY_SOCKS5_HOSTNAME proxies with curl and disable ‘proxy-resolver-mode’
4. If possible, do not set a proxy environment variable to ‘socks5h://’

For a more thorough demonstration of how Aqua can help you detect and address this vulnerability watch this video.