Long-awaited curl vulnerability flops

Apair of highly anticipated vulnerabilities revealed on Wednesday in a ubiquitous piece of open source software appear to be far less threatening than many researchers feared.

The two vulnerabilities impact the curl and libcurl programs, which are believed to have been installed some 50 billion times and are used to transfer files using network protocols. The two programs represent basic building blocks of the internet, and a sufficiently severe bug impacting them might impact nearly anything connecting to a web server.

The release of two bugs had been highly anticipated in the security community, with the program’s lead developer, Daniel Stenberg, describing the bug as “the worst curl security flaw in a long time.”

But security researchers expecting the next Log4Shell — an easily exploitable vulnerability with a huge install base — were disappointed that the bug is only exploitable in rare circumstances.

A maintainer for Redhat’s CentOS who released a fix around 14 hours earlier than anticipated revealed the vulnerability to be a buffer overflow issue that can only be taken advantage of under highly specific circumstances. Researchers awaiting the patch either breathed a sigh of relief or expressed annoyance that the bug was not as serious as initially thought.

The more severe of the two vulnerabilities revealed Wednesday revolves around using curl to connect through SOCKS5 — a proxy frequently used by Tor and virtual private networks — from a malicious website that has a hostname longer than 255 bytes. Stenberg theorized that the most “realistic” use case is someone using Tor to visit a malicious HTTPS site that takes advantage of this specific vulnerability.

“There’s a big difference between vulnerabilities where an attacker can scan the internet and exploit anyone who is running vulnerable versions,” said David Brumley, a cybersecurity professor at Carnegie Mellon University and the CEO of the cybersecurity firm ForAllSecure. “This is one where if someone goes to a malicious website and they have a vulnerable version they can get exploited.”

Computer security experts concluded Wednesday that setups at risk of being attacked using the vulnerability were far more likely to get hit using easier-to-execute techniques. “If you accept data, not validate it, and just blindly pass it to libraries like curl, you will likely have other problems that are easier to exploit,” Johannes B. Ullrich, the dean of research at the SANS Technology Institute wrote.

In revealing the vulnerability, Stenberg also explained in a blog post how the bug occurred. “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,” he wrote.

Stenberg’s explanation offers a rare bit of insight about how bugs can happen in the first place, sharing why the new feature was introduced and his thinking when he wrote the code that resulted in the bug.

Stenberg pointed out that using a memory-safe language would have avoided the entire problem but noted that the transition to these languages is “happening in a near glacial speed and shows with painful clarity the challenges involved.”

The Biden administration has been pushing developers and big tech companies to embrace memory safe languages as a tool to eliminate entire classes of bugs. According to Stenberg, 41% of security vulnerabilities found in curl would not have occurred if a memory-safe language had been used.

Others argued that the hype leading up to Wednesday’s release obscured what should be a routine process.

“Vulnerabilities are going to come out. There will be a new one next week. There is going to be a new one next year,” said Omkhar Arasaratnam, general manager of Linux Foundation’s Open Source Security Foundation. “What I would recommend to all organizations is get practiced in being able to receive, triage and take action against the vulnerabilities as they come out. This shouldn’t be a surprise. It shouldn’t be manic and hectic every time a vulnerability comes out.”

Arasaratnam said that it’s not often a vulnerability on such a vital software gets a warning, and noted that companies should have a solid software bill of materials so that when there is an expected bug, it can be quickly patched with some precautionary research.