Written in C, the popular curl and libcurl tools, which are installed in some six billion devices worldwide, are exposed to well-known security problems arising from the use of a non-memory safe language. A new initiative now aims to provide a memory-safe HTTP/HTTPS backend for curl based on Rust Hyper library.
While it is true that not all vulnerabilities stem from memory-safety issues and that curl should not be considered "unsafe", writes its creator and maintainer Daniel Stenberg, the use of a language like Rust, known for its memory-safety guarantees, could contribute to making its implementation safer, hence more secure. Indeed, as one commenter on Hacker News observes,
19 of the last 22 vulnerabilities (since 2018) have C-induced memory unsafety as a cause.
Yet, this does not mean curl will be rewritten in Rust. This is, according to Stenberg, a daunting task that is doomed to fail because it would be extremely hard to guarantee that the new implementation retains compatibility with all its clients out there.
Instead, the approach Stenberg will adopt is adding a new backend to curl. A backend in curl is a component that usually leverages some third-party library to carry through some specific task. For example, curl has backend for TLS, SSH, name resolution, LDAP, etc. In this sense, curl and libcurl act as a bridge from a well-known and established API/ABI to the specific backends that are compiled into it.
The Rust library Stenberg will base its work on is Hyper, a fast HTTP/1 and HTTP/2 implementation that aims to be highly concurrent and fast. The first step will be having Hyper to provide a C API and Stenberg sees many possible hurdles that may slow down development and make fixing a timeline almost impossible.
Actually, Hyper will not be the first Rust library to power a curl backend, with quiche and Mesalink being already part of the curl ecosystem. If Stenberg's effort proves successful, this might lead to a number of other backends being implemented in Rust.
Truth be told, using a language with memory-safety guarantees like Rust is no bullet-proof guarantee you will have no memory safety issue in a piece of code. As a matter of fact, all memory-safe languages enable special constructs to mark chunks of code as unsafe so the compiler can relax its behaviour. This is also the case with Rust and Hyper, which has 52 dependencies and includes over 1500 instances of unsafe code blocks.
Stenberg's effort will be funded by ISRG, the organization behind Let's Encrypt.
We’d like to thank Daniel for his willingness to be a leader on this issue. It’s not easy to make such significant changes to how wildly successful software is built, but we’ve come up with a great plan and together we’re going to make one of the most critical pieces of networking software in the world significantly more secure. We think this project can serve as a template for how we might secure more critical software, and we’re excited to learn along the way.
As a part of this effort, while Stenberg will work on adding support for Hyper, ISRG engineers will add support for Rustls as a TLS backend. Rustls has been audited for cryptographic correctness with extremely encouraging results. In particular, no issues were found and the final report stressed rustls authors' ability to correctly implement TLS without incurring common pitfalls.
Stenberg has already created a branch to work on Hyper and is working towards his first milestone, running a single curl test case successfully without any modifications.