Carnegie Mellon University
Browse

What Recent Vulnerabilities Mean to Rust

Download (116.35 kB)
online resource
posted on 2024-04-29, 20:50 authored by David SvobodaDavid Svoboda

In recent weeks several vulnerabilities have rocked the Rust community, causing many to question the safety of the borrow checker, or of Rust in general. In this post, we will examine two such vulnerabilities: The first is CVE-2024-3094, which involves some malicious files in the xz library, and the second is CVE-2024-24576, which involves command-injection vulnerabilities in Windows. How did these vulnerabilities arise, how were they discovered, and how do they involve Rust? More importantly, might Rust be susceptible to more similar vulnerabilities in the future? Last year we published two blog posts about the security provided by the Rust programming language. We discussed the memory safety and concurrency safety provided by Rust’s borrow checker. We also described some of the limitations of Rust’s security model, such as its limited ability to prevent various injection attacks, and the unsafe keyword, which allows developers to bypass Rust’s security model when necessary. Back then, our conclusion was that no language could be fully secure, yet the borrow checker did provide memory and concurrency safety when not bypassed with the unsafe keyword. We also examined Rust through the lens of source and binary analysis, gauged its stability and maturity, and realized that the constraints and expectations for language maturity have slowly evolved over the decades. Rust is moving in the direction of maturity today, which is distinct from what was considered a mature programming language in 1980. Furthermore, Rust has made some notable stability guarantees, such as promising to deprecate rather than delete any crates in crates.io to avoid repeating the Leftpad fiasco.

History

Publisher Statement

This material is based upon work funded and supported by the Department of Defense under Contract No. FA8702-15-D-0002 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The view, opinions, and/or findings contained in this material are those of the author(s) and should not be construed as an official Government position, policy, or decision, unless designated by other documentation. References herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by Carnegie Mellon University or its Software Engineering Institute. This report was prepared for the SEI Administrative Agent AFLCMC/AZS 5 Eglin Street Hanscom AFB, MA 01731-2100. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. [DISTRIBUTION STATEMENT A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution.

Copyright Statement

Copyright 2024 Carnegie Mellon University.

Usage metrics

    Exports

    RefWorks
    BibTeX
    Ref. manager
    Endnote
    DataCite
    NLM
    DC