The risky connections between software and memory1 are commonly known to cause safety concerns in software. It is projected that around 70% of serious vulnerabilities2 in memory-unsafe codebases arise from memory safety flaws. Malicious individuals exploit these weaknesses, leading to tangible harm in the real world. In 2023, Google’s threat intelligence teams conducted a comprehensive study across the industry and observed a close to all-time high number of exploited vulnerabilities. Our internal assessment indicates that 75% of Common Vulnerabilities and Exposures (CVEs) utilized in zero-day exploits are related to memory safety vulnerabilities.
At Google, we have been conscious of these concerns for more than two decades and are continuously striving to boost the level of memory protection in the software we utilize and create. Our commitment to Secure by Design underscores the integration of security elements, such as solid memory safety practices, across the entire software development cycle. This proactive stance promotes a safer and more reliable digital ecosystem for all users.
This article expands on our previously published Viewpoint on Memory Safety, and introduces our strategic plan towards memory safety enhancement.
Our Progression
Google’s path with memory safety is closely linked with the progression of the software industry itself. In our early years, we grasped the significance of balancing performance with security. This led to the early adoption of memory-safe languages like Java and Python, as well as the inception of Go. Presently, these languages compose a significant portion of our codebase, providing memory protection among other advantages. Conversely, the majority of our code is primarily authored in C++, which was historically the preferred choice for high-performance requirements.
We acknowledged the inherent risks associated with memory-unsafe languages and developed tools like sanitizers, which dynamically identify memory safety flaws, and testing tools like AFL and libfuzzer, which proactively evaluate the resilience and security of a software application by continuously providing unexpected inputs. By open-sourcing these tools, we have empowered developers worldwide to lessen the probability of memory safety vulnerabilities in C and C++ codebases. Expanding on this commitment, we offer ongoing fuzzing to open-source projects through OSS-Fuzz, which aided in identifying and rectifying over 8800 vulnerabilities across 850 projects.
Today, with the emergence of high-performance memory-safe languages like Rust and a deepening understanding of the limitations of detection-based approaches, we are primarily focused on preventing the introduction of security vulnerabilities on a large scale.
Looking Ahead: Google’s Two-Pronged Plan
Google’s long-standing strategy for addressing memory safety challenges is multi-faceted, acknowledging the necessity to handle existing codebases and future development while maintaining business momentum.
Our overarching goal is to gradually and consistently integrate memory-safe languages into Google’s codebases while phasing out memory-unsafe code in new developments. Considering the substantial amount of C++ code we utilize, we anticipate that a residual portion of mature and stable memory-unsafe code will persist for the foreseeable future.
Illustration showcasing growth of memory-safe languages as memory-unsafe code undergoes hardening and phased reduction over time.
Transition to Memory-Safe Languages (MSLs)
The first aspect of our strategy focuses on further expanding the adoption of memory-safe languages. These languages considerably reduce the risk of memory-related errors through features like garbage collection and borrow checking, embodying the same Secure Coding3 principles that effectively eradicated other vulnerability categories like cross-site scripting (XSS) on a broad scale. Google has already embraced MSLs such as Java, Kotlin, Go, and Python for a substantial portion of our codebase.
Our next goal is to intensify the presence of memory-safe languages with the required capabilities to cater to a broader spectrum of our low-level environments where C++ has traditionally held dominance. For instance, we are investing in expanding Rust’s implementation at Google beyond Android and other mobile usage scenarios into our server, application, and embedded ecosystems. This will enable the utilization of MSLs in low-level coding environments where C and C++ have typically held sway. Additionally, we are exploring smoother interconnectivity with C++ through Carbon to expedite more of our transition to MSLs.
In Android, which powers billions of devices and stands as one of our key platforms, we have already made progress in adopting MSLs, including Rust, in various parts of our network, firmware, and graphics layers. Our focus has been on integrating memory safety in freshly developed code rather than rewriting well-established memory-unsafe C or C++ codebases. As previously highlighted, this strategy is guided by vulnerability trends as memory safety vulnerabilities were typically introduced shortly before detection.
Consequently, the count of memory safety vulnerabilities reported in Android has notably and swiftly decreased, plummeting from over 220 in 2019 to an estimated 36 by the end of this year, showcasing the efficacy of this strategic pivot. Recognizing the severity of memory-safety vulnerabilities, the decline in such vulnerabilities is paving the way to a.coincident reduction in vulnerability severity, indicating a decrease in security risk.
Risk Mitigation for Memory-Unsound Code
Although shifting to memory-safe languages is the prolonged strategy that entails current investment, we acknowledge the immediate duty we hold to safeguard the well-being of our vast user base during this progression. This means acknowledging the existence of a substantial codebase composed in memory-unsafe languages (MULs) such as C and C++.
Hence, the second cornerstone of our approach concentrates on risk alleviation & confinement of this section of our codebase. This encompasses:
- C++ Strengthening: We are integrating safety measures extensively in our memory-unreliable code, drawing from our expertise in eradicating web vulnerabilities. While we won’t render C and C++ memory-safe, we are eradicating particular types of vulnerabilities in our proprietary code, as well as lessening the risks of the remaining vulnerabilities through exploit mitigations.
We have designated a share of our computational resources explicitly for boundary-checking the C++ standard library across our workloads. While the overhead of boundary-checking is minimal for individual applications, implementing it at Google’s scale necessitates substantial computing resources. This accentuates our profound commitment to amplifying the safety and security of our products and services. The initial outcomes are encouraging, and we’ll disclose more details in an upcoming post.
In Chrome, we have also been introducing MiraclePtr over the past few years, which has efficiently mitigated 57% of use-after-free vulnerabilities in privileged processes and has been associated with a decline in in-the-wild exploits.
- Safeguarding Measures: We are persistently4 enhancing critical elements of our software infrastructure through expanded utilization of isolation methodologies like sandboxing and privilege reduction, curtailing the potential impact of vulnerabilities. For instance, earlier this year, we rolled out the beta version of our V8 heap enclosure and integrated it into Chrome’s Vulnerability Reward Initiative.
- Defect Identification: We are allocating resources to defect identification tools and innovative exploration such as Naptime and facilitating ML-guided fuzzing to be as simple and extensive as testing. While we are increasingly migrating towards memory safety by design, these tools and techniques persist as a crucial element in proactively recognizing and diminishing risks, particularly against vulnerability categories currently lacking robust preventive measures.
Moreover, we are actively collaborating with the semiconductor and research communities on emerging hardware-based strategies to enhance memory safety. This encompasses our efforts to endorse and validate the effectiveness of Memory Tagging Extension (MTE). Device implementations are commencing, including within Google’s internal environment. We are also conducting ongoing research on Capability Hardware Enhanced RISC Instructions (CHERI) architecture, which can offer more precise memory protections and safety controls, especially beneficial in security-critical environments like embedded systems.
Envisaging the Future
We firmly believe it is crucial to welcome the prospect of attaining memory safety at a large scale, as it will positively impact the security of the broader digital framework. This forward path demands persistent investment and innovation to advance safety and speed, and we remain dedicated to collaborating with the wider community in traversing this journey together.
We will share forthcoming publications on memory safety that delves deeper into specific facets of our strategy.
Notes
-
Anderson, J. Computer Security Technology Planning Study Vol II. ESD-TR-73-51, Vol. II, Electronic Systems Division, Air Force Systems Command, Hanscom Field, Bedford, MA 01730 (Oct. 1972).
https://seclab.cs.ucdavis.edu/projects/history/papers/ande72.pdf ↩
-
https://www.memorysafety.org/docs/memory-safety/#how-common-are-memory-safety-vulnerabilities ↩
-
Kern, C. 2024. Developer Ecosystems for Software Safety. Commun. ACM 67, 6 (June 2024), 52–60. https://doi.org/10.1145/3651621 ↩
-
Barth, Adam, et al. “The security architecture of the chromium browser.” Technical report. Stanford University, 2008.
https://seclab.stanford.edu/websec/chromium/chromium-security-architecture.pdf ↩
-
About Author
