cURL
Naked Security Naked Security

cURL security audit learns the lessons of Heartbleed

You may not have heard of cURL but you probably use it all the time

You may not have heard of cURL but you’ve probably made use of it. It’s one of those pieces of software that does something everybody needs, that everybody uses but almost nobody pays any attention to.

Its mission in life is simple: if something has an URL, cURL can get it for you.

That often means fetching web pages or other data over HTTP, but it’s just as happy fetching things over FTP, IMAP, LDAP or any one of a bunch of other protocols.

The reason you haven’t heard of it is that it tends to get included in other, larger projects where it’s buried so deep the limelight can’t reach it.

According to the folks behind cURL, who describe their ubiquitous offering as “the internet transfer backbone for thousands of software applications” you’ll find it in everything from cars and printers to phones and TVs.

Popularity comes with its own risks though; a bug in the library that’s used by hundreds of pieces of software becomes a bug in hundreds of pieces of software.

Dullness and dependability have their risks too.

There is a serious danger with popular but unsexy open source projects like cURL of everyone leaving the grunt work of keeping it secure to somebody else. The assumption is that if it’s so popular there must be plenty of other eyeballs on it, keeping the bugs shallow, right?

It’s that kind of thinking that allowed the Heartbleed bug to fester inside the popular but unsexy OpenSSL library for more than two years before parking its tanks on our lawn in 2014.

Thankfully there are people paying serious attention to cURL. Most recently their number included Cure53, a firm of security analysts contracted by Mozilla’s SOS (Secure Open Source) program.

SOS was set up by Mozilla in the wake of the Heartbleed and Shellshock bugs to give open source developers working on cornerstone projects like OpenSSL and cURL access to expert security audits and fixes.

It was a service that cURL’s author and maintainer,

I feel that we’ve had some security related issues lately and I’ve had the feeling that we might be missing something … a serious problem in curl could have a serious impact on tools, devices and applications everywhere. We don’t want that to happen.

Cure53 uncovered 23 issues in the cURL source code; 14 “general weaknesses” and nine security vulnerabilities, of which four were graded “high” because of their potential to allow Remote Code Execution on affected systems.

Despite the bugs the analysts appear to have formed a favourable impression of Stenberg’s work, saying that “the overall impression of the state of security and robustness of the cURL library was positive”.

The audit and subsequent fixes resulted in cURL 7.51.0 and shows that a small number of eyeballs that know what they’re looking for can make bugs shallow too:

… the investigation involved five testers of the Cure53 team. The tool was tested over the course of 20 days in August and September of 2016 … rather than employ fuzzing or similar approaches to validate the robustness of the build of the application and library, the latter goal was pursued through a classic source code audit.

The full report contains details of all the issues uncovered in the audit along with written explanations and plenty of example code.

If you enjoy reading through the C code in the report you’ll be delighted to learn that there’s plenty more to look at in the the cURL source code itself, if you feel so inclined.