GoKawiilCVE is a database used for categorizing and reporting security vulnerabilities in software. There are various kinds of vulnerabilities that can be reported. Some of them are caused simply by bugs in the program logic (like a recent CVE reported in Cargo), but some of the most nasty ones are caused by memory unsafety, which can easily lead to exploits. In this post I want to focus on the latter kind of CVEs, how they are reported, especially in libraries, and how it differs between Rust and C or C++.
Because sometimes I see people online who compare the number of CVEs in Rust and C/C++ software, which tends to be accompanied by claims about Rust not being really memory safe or not being worth adopting when CVEs can still exist in it. And sometimes I also observe similar views when I teach Rust to programmers who are used to programming in C or C++.
Now, anyone is, of course, free to do such comparisons, and make their own conclusions based on it. But I think that there is an important difference in how potential vulnerabilities related to memory safety are treated in Rust and C/C++, which might not be obvious at first, especially if you don’t know how Rust works. I’d like to explain that in this post.
But first, I should clarify that it is absolutely possible to cause memory unsafety bugs and undefined behaviour in Rust. In the vast majority of cases, the unsafe keyword is required for this to happen, but anyone who claims that Rust programs cannot experience UB at all is simply incorrect. It is also perfectly possible to cause general vulnerabilities (meaning those unrelated to memory unsafety) in Rust. Forgetting to add a check that your admin dashboard is only accessible to admins can happen in any language, after all.
And yet, there is something very different between potential vulnerabilities in Rust and C or C++, which is related to the core reason of why Rust is actually much more memory safe in practice than C or C++. I’ll try to demonstrate it on the curl networking library, which is written in C.
Potential vulnerability in curl?
(lib)curl is one of the most used and well-maintained open source libraries in the world. Its primary developer, Daniel Stenberg, is one of the most prolific open source maintainers of our time, and together with many other people, he has been dilligently improving this library for the past 30 years. Despite having to deal with a recent avalanche of CVEs found by LLMs, he and his collaborators are doing a very good job of keeping curl safe from potential exploits and vulnerabilities, and they take pride in curl being a very robust piece of software.
So, let’s take that to the test, shall we? I opened the documentation of libcurl and found the first function I saw that accepts an argument, curl_getenv . This is supposed to be a simple function that provides a portable abstraction for getting the value of an environment variable across different operating systems. curl is supposed to be safe and robust, so surely this function doesn’t contain any UB or memory unsafety, right? So what about the following C program?
#include <curl/curl.h> int main ( void ) { curl_getenv ( NULL ); }
This 5-line C program is as simple as it gets, it just calls the curl_getenv function with a NULL pointer argument, and compiles without any warnings. And yet, when you execute it, you (might) get a segfault, and thus a memory safety bug, and thus a potential vulnerability/exploit:
... continue reading