For days now, the cybersecurity community has waited anxiously for the big reveal about two security flaws that, according to curl founder Daniel Stenberg, included one that was likely “the worst curl security flaw in a long time.”
Curl is an open source proxy resolution tool used as a “middle man” to transfer files between various protocols, which is present in literally billions of application instances. The suggestion of a massive open source library flaw evoked memories of the catastrophic log4j flaw from 2021. As Alex Ilgayev, head of security research at Cycode, worried, “the vulnerability in the curl library might prove to be more challenging than the Log4j incident two years ago.”
But following today’s unveiling of patches and bug details, neither vulnerability lived up to the hype.
Impacting a Limited Number of Curl Deployments
The first vuln, a heap-based buffer overflow flaw tracked under CVE-2023-38545, was assigned a rating of “high” due to the potential for data corruption or even remote code execution (RCE). The issue lies in the SOCKS5 proxy handoff, according to the advisory.
“When curl is asked to pass along the hostname to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that hostname can be is 255 bytes,” the advisory stated. “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.”
The bug could allow the wrong value to be handed off during the SOCKS5 handshake.
“Due to a bug, the local variable that means ‘let the host resolve the name’ could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too long hostname to the target buffer instead of copying just the resolved address there,” the advisory added.
However, the high severity designation only applies to a fraction of deployments, cybersecurity expert Jake Williams says.
“This is only high severity in very limited circumstances,” Williams says. “I think it’s just an issue that when you have a library vulnerability, you know know how the library is being used. You have to assign the CVE assuming a worst case scenario for implementation.”
The second curl bug, tracked under CVE-2023-38546, is a low-severity cookie injection flaw that only impacts the libcurl library, not curl itself.
“I think this is a bigger problem for security devices, and appliances (which fetch untrusted content and often use curl under the hood),” Andy Hornegold said in a statement in reaction to the release of the curl bug details. “I don’t see it being a huge problem for standalone usage.”
Dangers of Hyping Up a Fix
Beyond heartburn for cybersecurity teams, hyping up a fix before technical details are released can hand over an easy win to threat actors. In this instance, Williams points out that RedHat updated its change log ahead of the official curl release, which could have given cyberattackers important intel on unpatched targets, had the vulnerability been as dangerous as previously assumed.
Indeed, Mike McGuire with Synopsys saw the dangers of the amped up attention on the curl update and wrote about it in an Oct. 9 blog.
“Despite having no additional details about the vulnerability, threat actors will undoubtedly begin exploit attempts,” McGuire wrote. “Additionally, it’s not unheard of for attackers to post bogus ‘fixed’ versions of a project riddled with malware to take advantage of teams scrambling to patch vulnerable software.”