While the memory safety and security features of the Rust programming language can be effective in many situations, Rust’s compiler is very particular on what constitutes good software design practices. Whenever design assumptions disagree with real-world data and assumptions, there is the possibility of security vulnerabilities–and malicious software that can take advantage of those vulnerabilities. In this post, we will focus on users of Rust programs, rather than Rust developers. We will explore some tools for understanding vulnerabilities whether the original source code is available or not. These tools are important for understanding malicious software where source code is often unavailable, as well as commenting on possible directions in which tools and automated code analysis can improve. We also comment on the maturity of the Rust software ecosystem as a whole and how that might impact future security responses, including via the coordinated vulnerability disclosure methods advocated by the SEI’s CERT Coordination Center (CERT/CC). This post is the second in a series exploring the Rust programming language. The first post explored security issues with Rust.
A MITRE CVE search for “Rust” in December 2022 returned recent vulnerabilities affecting a wide range of community-maintained libraries but also cargo itself, Rust’s default dependency management and software build tool. cargo searches and installs libraries by default from crates.io, an online repository of mostly community-contributed unofficial libraries similar to other software ecosystems, such as Java’s Maven and the Python Package Index (PYPI). The Rust compiler developers regularly test compiler release candidates against crates.io code to look for regressions. Further research will likely be needed to consider the security of crates.io and its impact for vulnerability management and maintaining a software bill of materials (or software supply chain), especially if the Rust ecosystem is used in critical systems.