'ZDNET Recommends': What exactly does it mean?
ZDNET's recommendations are based on many hours of testing, research, and comparison shopping. We gather data from the best available sources, including vendor and retailer listings as well as other relevant and independent reviews sites. And we pore over customer reviews to find out what matters to real people who already own and use the products and services we’re assessing.
When you click through from our site to a retailer and buy a product or service, we may earn affiliate commissions. This helps support our work, but does not affect what we cover or how, and it does not affect the price you pay. Neither ZDNET nor the author are compensated for these independent reviews. Indeed, we follow strict guidelines that ensure our editorial content is never influenced by advertisers.
ZDNET's editorial team writes on behalf of you, our reader. Our goal is to deliver the most accurate information and the most knowledgeable advice possible in order to help you make smarter buying decisions on tech gear and a wide array of products and services. Our editors thoroughly review and fact-check every article to ensure that our content meets the highest standards. If we have made an error or published misleading information, we will correct or clarify the article. If you see inaccuracies in our content, please report the mistake via this form.
Nasty bug discovered in widely used Linux utility curl, and patches already rolled out
For the most part, ordinary Linux users don't know what curl is. Programmers and system administrators know the utility well, though.
This shell command and its associated library, libcurl, is used to transfer data over every network protocol you've ever heard of, and it's used in desktops, servers, clouds, cars, television sets, routers, and pretty much every Internet of Things (IoT) device. Curl's developers estimate it's used in over twenty billion instances. And now there's a potentially nasty security bug in it, CVE-2023-38545.
Also: Google Cloud, AWS, and Cloudflare report largest DDoS attacks ever
How nasty? Curl's lead developer, Daniel Stenberg, wrote in a blog post that it's "the worst security problem found in curl in a long time." He should know.
Security experts agree. This is, in a word, bad.
As Saeed Abbasi, Qualys Threat Research Unit Product Manager, warned:
Organizations must act swiftly to inventory, scan, and update all systems utilizing curl and libcurl. In particular, the gravity of the high-severity vulnerability mandates immediate and cautious attention to safeguarding interconnected and web-aware applications, ensuring the rich data transfer functionality curl and libcurl provide remain unimpaired and secure.
Specifically, the security hole can be invoked when someone is using the SOCKS5 proxy protocol. This rather simple protocol sets up network communication via a dedicated "middleman." The protocol is used when communicating over Tor, the open-source internet software used to enable anonymous communication and to access the internet from within organizations and companies privately. Some virtual private networks, such as NordVPN, Private Internet Access, and Hide.Me, offer it to enable their users to get around internet content blocks and to ensure their anonymity.
In a Mastodon conversation, Steinberg said, "Perhaps most realistically, a Tor user (which normally uses SOCKS5) going to a HTTPS site that has been breached or similar" is the most likely to fall into this security hole.
Also: 7 things even new Linux users can do to better secure the OS
CVE-2023-38545 is a memory heap overflow hole. It can possibly be exploited for remote code execution. There are already proofs of concept showing how an attack could be made using the curl hole.
The security hole was introduced in February 2020 and affects libcurl versions from 7.69.0 to and including 8.3.0.
Steinberg is embarrassed by his mistake:
Reading the code now, it is impossible not to see the bug. Yes, it truly aches having to accept the fact that I did this mistake without noticing and that the flaw then remained undiscovered in code for 1315 days. I apologize. I am but a human. … In hindsight, shipping a heap overflow in code installed in over twenty billion instances is not an experience I would recommend.
Not everyone thinks it's that big a deal. Bill Demirkapi, a member of the Microsoft Security Response Center Vulnerability and Mitigations team, tweeted on Twitter, aka X, that, "The 'worst security problem found in curl in a long time' is only accessible if the victim is using a SOCKS5 proxy & connects to a rogue server or is under a MitM [Man in the Middle] attack? I'm going back to sleep."
Less snarkily, the software supply chain company JFrog observed:
It can be assumed with good confidence that this vulnerability will get exploited in the wild for remote code execution, with more sophisticated exploits being developed. However – the set of pre-conditions needed in order for a machine to be vulnerable (see previous section) is more restrictive than initially believed. Therefore, we believe the vast majority of curl users won't be affected by this vulnerability.
To be precise, the preconditions needed to spark the problem into a curl security fire are:
The curl request is made via socks5h.
The curl state machine's negotiation buffer is smaller than ~65k.
The SOCKS server's "hello" reply is delayed.
The attacker sets a final destination hostname larger than the negotiation buffer.
That's a lot of preconditions.
Still, given Curl's extensive use across various operating systems, applications, and IoT devices, Steinberg's early announcement of the problem was a smart strategic move. It provided organizations ample time to audit their systems, identify all instances of curl and libcurl in use, and develop a comprehensive plan for enterprise-wide patching.
Also: Newly discovered Android malware has infected thousands of devices
The curl project didn't stop there; information about the flaws was concurrently shared with developers of various Linux, Unix, and Unix-like distributions. This collaborative approach ensured that patches and updated packages were ready before the official release of curl v8.4.0.
So both I and the curl project strongly recommend users to update to curl/libcurl version 8.4.0 or apply patches to older versions to mitigate the risks associated with these vulnerabilities.
Since libcurl/curl is a default component in many Linux distributions and baked into numerous container images, Linux users should be vigilant and look out for releases by these providers. Most of the major Linux distributors already have the patches out.