For the most part, Linux users don’t know what curl is. On the other hand, programmers and system administrators are familiar with this utility.
This shell command and its associated library, libcurl, are used to transfer data over network protocols, and they are used in desktop computers, servers, cloud instances, cars, televisions, routers, and virtually everything Internet of Things (IoT) devices. Curl’s developers estimate that it is used in over twenty billion instances. And here comes a potentially very unpleasant security bug, CVE-2023-38545.
What do you mean ? Curl’s lead developer, Daniel Stenberg, wrote in a blog post that this is “the worst security issue discovered in curl in a long time.” He knows firsthand. Security experts agree. In a word, it’s not good at all.
Possible for remote code execution
As Saeed Abbasi, product manager of Qualys’ threat research unit, warned:
Organizations should act quickly to inventory, scan, and update all systems using curl and libcurl. The severity of this vulnerability requires immediate attention to protect interconnected and web-aware applications, ensuring that the rich data transfer capabilities provided by curl and libcurl remain intact and secure.
Specifically, the security flaw can be invoked when someone uses the SOCKS5 proxy protocol. This fairly simple protocol establishes network communication via a dedicated “intermediary”. The protocol is used to communicate via Tor, the open-source internet software used to enable anonymous communications and to access the internet from inside organizations and businesses privately. Some virtual private networks (VPNs), such as NordVPN and Hide.Me, use it to allow their users to bypass Internet content blocks and ensure their anonymity.
Mr. Steinberg said: “A Tor user (who normally uses SOCKS5) going to an HTTPS site that has been breached or similar issue” is most likely to fall for this vulnerability. security.
CVE-2023-38545 is a memory overflow vulnerability. It can be leveraged for remote code execution. There is already proof of concept showing how an attack could be carried out using the curl flaw. The security flaw was introduced in February 2020 and affects libcurl versions ranging from 7.69.0 to 8.3.0 inclusive.
A real embarrassment for the developer
Steinberg is embarrassed by his mistake:
Reading the code now, it’s impossible not to see the bug. Yes, it really hurts to have to accept the fact that I made this mistake without realizing it and then the flaw remained undiscovered in the code for 1315 days. I am sorry for that. I’m only human. …In hindsight, delivering an overflow flaw in code installed in over twenty billion instances is not an experience I would recommend.
Not everyone thinks this is a big deal. Bill Demirkapi, member of the Microsoft Security Response Center Vulnerability and Mitigation team, tweeted on Twitter, aka“The ‘worst security issue discovered in curl in a long time’ is only accessible if the victim uses a SOCKS5 proxy & connects to a rogue server or suffers a MitM attack [Man in the Middle] ? (I’m going to go back to sleep).”
Less sarcastic, software supply chain company JFrog noted the following:
It is safe to assume that this vulnerability will be exploited for remote code execution. However, the set of prerequisites needed for a machine to be vulnerable is more restrictive than initially thought. Therefore, we believe that the vast majority of curl users will not be affected by this vulnerability.
To be precise, the prerequisites needed for the issue to turn into a real curl security issue are as follows:
- The curl request is made via socks5h.
- The curl machine’s trading buffer is less than ~65k.
- The “hello” response from the SOCKS server is delayed.
- The attacker sets a final destination hostname larger than the handshake buffer.
That’s a lot of prerequisites.
A smart strategic decision
Still, considering Curl’s wide use in various operating systems, applications, and IoT devices, Steinberg’s announcement of the issue was a smart strategic move. It gave organizations ample time to audit their systems, identify all instances of curl and libcurl in use, and develop a comprehensive enterprise-wide remediation plan.
The curl project didn’t stop there; Information about the flaws was simultaneously 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.
The curl project and I therefore strongly recommend that users update to version 8.4.0 of curl/libcurl or patch earlier versions to mitigate the risks associated with these vulnerabilities.
Since libcurl/curl is a default component in many Linux distributions and is integrated into many container images, Linux users should be vigilant and monitor the versions released by these vendors. Most major Linux distributors have already released the patches.
Source: “ZDNet.com”