Once seen as an invincible utility tool, Curl, the widely embraced Linux utility, had its defenses cracked open by a hazardous bug, sparking a race against time to patch up the breach before disaster struck. This is the tale of how a looming digital menace was identified and neutralized, underscoring the relentless vigilance required in the cyber realm.
In the heart of countless digital operations, Curl facilitates data transfer over a myriad of network protocols. From desktops and servers to the veins of the Internet of Things (IoT), its influence extends to an estimated 20 billion instances. Yet, a sinister flaw threatened to shatter this fortress of digital exchange.
Dubbed CVE-2023-38545, the bug was a heap-based buffer overflow anomaly lurking in the shadows of the SOCKS5 proxy protocol utilized by Cur. This flaw was a ticking time bomb, with the potential to corrupt data and, in dire circumstances, execute arbitrary code, ushering in a realm of cyber chaos.
The saga began on a seemingly ordinary day, October 4, 2023, when one of Curl’s core maintainers, Daniel Stenberg, unveiled a plan to release a fortified version of Curl, 8.4.0, on October 11, 2023. This version was to be the knight in shining armor, destined to vanquish the menacing CVE-2023-38545 along with another lesser foe, CVE-2023-38546.
The nefarious CVE-2023-38545 primarily targeted both the Curl command-line tool and libcurl, affecting versions from 7.69.0 up to and including 8.3.0. However, the sinister bug could not unleash its wrath under default conditions. Its powers could only be invoked if Curl was maneuvered in specific ways, such as setting `CURLOPT_PROXYTYPE` to `CURLPROXY_SOCKS5_HOSTNAME` or manipulating proxy settings to use the scheme `socks5h://`. The Curl CLI tool was only susceptible if executed with certain flags or environment variables set to use the malicious `socks5h://` scheme.
While the malicious bug was veiled in intricacy, requiring a specific set of conditions to be met for exploitation, the potential aftermath was nothing short of catastrophic. The bug could be harnessed for remote code execution (RCE), a nightmare scenario where attackers could remotely hijack systems, unleashing a torrent of cyber assaults across the globe.
Proof-of-Concepts (PoCs) demonstrating the bug’s ability to induce a Denial of Service (DoS) attack soon surfaced, raising alarms across the cyber domain. Although a full-fledged remote code execution exploit was yet to be unearthed, the hazard loomed large, with experts fearing sophisticated exploits might soon follow.
Linux users were thus summoned to vigilance, with a clarion call sent out for prompt patching to barricade against this digital specter. The majority heeded the call, with patches swiftly released to seal off the vulnerability and restore the digital equilibrium.
This episode underscores the perpetual battle against cyber threats, even in the most trusted of digital utilities. It serves as a stark reminder of the urgency for relentless scrutiny and prompt action in safeguarding our digital dominions from unseen adversaries.
In the annals of cyber history, the tale of CVE-2023-38545 and the proactive measures taken to nullify its threat will be etched as a testament to the indomitable spirit of the digital guardians who stand vigil over our interconnected realms.
The new vulnerability in the curl library might prove to be more challenging than the Log4j incident two years ago.
The curl project, or libcurl (the library powering curl), is one of the most popular open-source projects and is one of the foundational networking utilities in the Unix and Linux ecosystems.
As part of cloud-native development processes, this library can be used in many ways – introducing it into the code, using it as a dependency, using it as part of the operating system bundle, using it as part of the Docker container, installed on Kubernetes cluster nodes, and many more.
Before the October 11 release of the security advisory, organizations should evaluate their software delivery processes and identify where libcurl is used. This can be accomplished with the help of SCA tooling for code, container scanning, SBOM tooling, and ASPM capabilities. Those organizations not using security tools that provide transparency into their software delivery process will struggle to update this widespread vulnerability.
“The security community has been waiting with bated breath for the better part of a week to find out the next steps in navigating a pair of high-severity vulnerabilities that exist in affected versions of the Curl library. With the patch officially out, many of us had our suspicions of a serious remote code execution flaw confirmed. Sadly, Curl has seen a few serious security issues before, despite doing security audits and bug bounties.
This dependency is widely regarded as a foundational pillar of the internet, and there is no getting around that if successfully leveraged, we are at increased general risk online as a result. There are similarities with the devastating Log4Shell attack in Log4j, another vulnerable dependency that is still being exploited almost two years later.
The vulnerability is known as a Heap-based buffer overflow, which is quite an old software vulnerability by any measure. However, perhaps the one shield of defense we have is that the communication must go through a SOCKS5 proxy, which, in my opinion, is not a very common deployment. However, security researchers – good and bad – tend to be highly creative, and with today’s disclosure of vulnerability information, will be pulling out all stops to find every avenue to mass-exploit these weaknesses through other means.
While there is no one failsafe method to eliminate all vulnerabilities in software, a code-level vulnerability of this nature could be stopped before entering production if developers were in a state of heightened security awareness on how to avoid these types of early-2000s bugs.”
“Initially the vulnerability in curl/libcurl was announced with commentary that it was probably the worst security flaw in Curl in a long time and that the patch release cycle was being cut short, causing some alarm within the security community.
On balance this alarm was justified due to aforementioned commentary and the fact that significant bugs in software libraries are notoriously difficult to detect if and where they are used in enterprise software packages. These issues get more serious still where they are present in applications that are internet accessible – rather expected of libcurl. This was the case for Log4J, which was so severe as it presented such a broad attack surface.
In this case, the vuln seems to be related to SOCKS5 local DNS resolution where hostname > 255 chars. This appears to limit the attack surface to implementations where SOCKS is in use, and for an attacker to control the hostname or redirect of a page (although this may be achieved with a 0 click method using prefetch functionality in applications that uses CURL). It does make for a bunch of interesting exploit scenarios, but as far as we can currently tell – nothing internet melting, and a far cry from the tagline ‘curlmageddon’ that some had assigned to the vulnerability.”