For those who might not know, curl is a command-line tool and library for transferring data over various protocols. It’s not just a tool for the tech-savvy; it’s part of countless software applications that people use daily.
The disclosed bug
Finally, the long-awaited details are out. The bug, known as CVE-2023-38545, is a heap buffer overflow that happens during the SOCKS5 proxy handshake. Basically, if curl is told to let the SOCKS5 proxy resolve the hostname, and that hostname is longer than 255 bytes, things go south.
Here’s the nitty-gritty. Curl is supposed to switch to local name resolving if the hostname is too long. Due to a bug, curl can mistakenly still pass on that long hostname to the proxy. This results in overwriting the heap-based buffer, and that’s a big no-no.
Who’s affected?
The vulnerable versions are from libcurl 7.69.0 up to 8.3.0. If you’re using any of these versions, it’s time to take action. Particularly, applications that do not set the CURLOPT_BUFFERSIZE option, or set it to something smaller than 65541, are at risk.
If you’ve used options like CURLOPT_PROXYTYPE set to CURLPROXY_SOCKS5_HOSTNAME, or have proxy environment variables set to use the socks5h:// scheme, you should be extra cautious.
Why is this a big deal?
Well, first off, this isn’t just a coding error; it’s a security vulnerability. Heap overflow issues like this one can be exploited to run malicious code. Imagine an attacker using a specially crafted URL to trigger this bug. They could potentially execute code or leak sensitive data.
What now?
You’ve got some options here. The simplest one is to update to curl version 8.4.0 where this issue has been fixed. If you can’t do that, apply the patch to your local version. Alternatively, you can stop using CURLPROXY_SOCKS5_HOSTNAME proxies or avoid setting your proxy environment variables to socks5h://.
With the details disclosed, it’s clear that this was a ticking time bomb. The flaw affects a wide range of versions and could potentially be exploited in numerous ways. It’s crucial to act fast. Update your systems, patch what you can, and be wary of the configurations you use.
Now you’re in the know. Don’t wait; fix this issue as soon as you can.
How did the bug occur in the first place?
Daniel Stenberg, the maintainer of curl, shared some deep insights about how this bug was introduced in curl.
So how did it happen? The story goes back to early 2020, when Daniel took it upon himself to improve a function that connects to SOCKS5 proxies. His aim was to make it non-blocking, so it would perform better when handling multiple transfers. Daniel succeeded in doing this, but also unintentionally introduced the bug that became CVE-2023-38545.
The bug exists in the SOCKS5 hostname resolution part of the code. When the hostname is too long (over 255 bytes), the function shifts from proxy-side to local-side resolution. The catch is that this setting gets reset when the function is called again, essentially forgetting the decision to switch to local resolution. Next, curl tries to copy this oversized hostname into a buffer that’s not big enough for it, causing a heap overflow. Yikes!
The size of the target buffer varies, but if it’s less than 65541 bytes, the overflow can occur. Even more concerning is that an attacker who controls an HTTPS server can exploit this. They can send a malformed redirect that, when processed by a curl client, triggers the heap overflow.
In short, the bug occurred because the function failed to remember its decision to switch from remote to local hostname resolution. It then tried to cram a too-large hostname into a too-small buffer, leading to the heap overflow.
Daniel points out that a memory-safe language could have prevented this, but for now, curl remains in C. They’ve now added a test case for this issue, and the function has been corrected to not switch modes so recklessly. A $4,660 bug bounty was paid for identifying this issue, marking it as pretty significant in the curl community.
Below is the announcement article of this bug that was written on October 5.
On October 11, curl will roll out its new release, version 8.4.0. The update will address a particularly nasty security flaw rated as “HIGH” in severity. This isn’t some run-of-the-mill bug.
According to the maintainers, this is probably the worst curl security issue they’ve seen in a long time. But what exactly is curl, and why does this matter?
What is curl?
For those who might not be in the know, curl is a command-line tool and library that lets you transfer data over a wide variety of protocols. It’s not just an esoteric utility for tech wizards; it’s a core component in thousands of software applications, including ones you probably use every day.
Now you get why a “HIGH” severity flaw in curl is something to pay attention to.
The Details We Have
The information about the upcoming update was posted by the project’s maintainer, Daniel “badger” Stenberg, on the project’s GitHub discussion forum. The specifics about the two Common Vulnerabilities and Exposures (CVEs) remain under wraps until the release, slated for 06:00 UTC on October 11.
Here’s what we do know:
- CVE-2023-38545: High severity, affects both libcurl and the curl tool
- CVE-2023-38546: Low severity, affects libcurl only
No changes are expected in the API or ABI, which is good news for developers concerned about compatibility issues.
Why so secretive?
The project maintainers are tight-lipped about which versions of curl are affected by these flaws. Disclosing such details now could help nefarious types pinpoint the vulnerabilities with unnerving accuracy.
What we do know is that this vulnerability has been lurking in “the last several years” of curl versions. Yep, it’s been out there, under the radar, waiting to be discovered.
The maintainers aren’t rushing the patch. They’ve chosen the release date to:
- Allow for further internal review and advisory drafting.
- Give distribution maintainers a heads-up to prep their patches.
- Sync up internal logistics for the new release.
Sure, there’s a tiny risk that someone could unearth this flaw before the patch is out, but given that it’s remained undetected for so long, they believe it’s a risk worth taking.
Who is most affected by this flaw?
It goes without saying that, if you’re a developer and curl is anywhere in your stack, this flaw needs your immediate attention.
- REST API Clients: If your application is making HTTP/HTTPS requests via curl to RESTful services, the high-severity flaw should be a red alert. It might compromise the data being sent or received, posing a significant risk for both your application and the API endpoints it interacts with.
- Web Scraping Tools: Many web scraping tools and libraries depend on curl for retrieving web pages. A vulnerability here could expose sensitive information or even lead to remote code execution.
- Data Transfer in Microservices: If you’re running a microservices architecture where services communicate over HTTP/HTTPS, the flaw could be a critical weak link, potentially compromising the data integrity between services.
- IoT Devices: IoT devices often use lightweight software to interact with the web, and curl fits that bill. A vulnerability could provide a way to compromise these devices, a nightmare scenario for IoT ecosystems.
- Deployment Scripts: DevOps practices often involve automated scripts for deployment that make use of curl to pull in software packages, configuration files, or even to interact with internal REST APIs. These could be compromised if the flaw is exploited.
- Package Managers: Some package managers use curl to fetch packages from remote repositories. An exploit could tamper with the downloaded packages, leading to all sorts of nasty outcomes, from data leaks to remote code execution.
- CI/CD Pipelines: Continuous Integration and Continuous Deployment pipelines often use curl commands for interacting with web services, uploading artifacts, or triggering webhooks. An exploited vulnerability could derail the entire CI/CD process.
- Cloud Services Interactions: If you’re using curl in a script to interact with AWS S3, Google Cloud Storage, or any other cloud service’s API, the flaw could potentially expose sensitive data or credentials.
- VPN Software: Some VPN services make use of libcurl for handling certain tasks. Here, exploitation could lead to a privacy breakdown or worse.
It’s a high-severity issue that has the potential to disrupt a wide range of software projects, applications, and platforms.
Bottom Line
Mark October 11 on your calendars. If you’re a developer, sysadmin, or just someone who uses applications that rely on curl, you’ll want to update as soon as the patch rolls out. It’s not every day that a “HIGH” severity flaw comes to light in a tool as ubiquitous as curl, and when it does, it’s all hands on deck to get it fixed.
Now you know. Plan accordingly.
