Over half of open source projects contain code written in memory-unsafe languages. U.S. Cybersecurity and Infrastructure Security Agency Report Found: Memory unsafe means that code allows operations that can corrupt memory, leading to vulnerabilities such as buffer overflows, use after free, and memory leaks.
The report’s findings, released in collaboration with the FBI, the Australian Communications Signals Directorate’s Australian Cyber Security Centre and the Canadian Cyber Security Centre, are based on an analysis of 172 critical projects defined by the OpenSSF’s Securing Critical Projects Working Group.
Of the total lines of code in these projects, 55% are written in memory-unsafe languages, with larger projects containing even more. Memory-unsafe lines make up more than a quarter of the total lines in the top 10 projects in the dataset, with a median percentage of 62.5%. Four of these projects contain more than 94% memory-unsafe code.
What are memory unsafe languages?
Memory-unsafe languages such as C and C++ require developers to manually implement strict memory management techniques, including careful allocation and freeing of memory. Naturally, mistakes will happen, resulting in vulnerabilities that could allow attackers to take control of your software, your system, and your data.
On the other hand, memory-safe languages like Python, Java, C#, and Rust handle memory management automatically through built-in features, shifting that responsibility to the interpreter or compiler.
look: 10 Python Courses Worth Taking in 2024
“Memory safety vulnerabilities are among the most common types of software vulnerabilities and generate significant costs for both software manufacturers and consumers associated with patching, incident response, and other efforts,” the report authors wrote.
We also analyzed the software dependencies of three projects written in memory-safe languages and found that each project depends on other components written in non-memory-safe languages.
“We therefore conclude that most important open source projects we analyzed contain potential memory safety vulnerabilities, even if they are written in memory-safe languages,” the authors write.
“This discovery certainly poses a risk for both commercial and government organizations because when you look at the year-to-year exploitation across vulnerability classes, this class of vulnerability is being widely exploited,” Chris Hughes, chief security advisor at open source security firm Endor Labs and a cyber innovation fellow at CISA, told TechRepublic. Most commonly exploited classes of vulnerabilities “Year-over-year.”
Why is memory-unsafe code so prevalent?
Memory-unsafe code is prevalent because it allows developers to directly manipulate hardware and memory, which is useful where performance and resource constraints are critical, such as in operating system kernels and drivers, and in cryptography and networking in embedded applications. The report authors observe that this is a trend they expect to continue into the future.
Developers may use memory-unsafe languages directly because they are unaware or don’t care about the risks, or they may intentionally disable memory safety features of memory-safe languages.
However, those who are aware of the risks and do not want to include memory-unsafe code may unintentionally include memory-unsafe code through dependencies on external projects. Performing a comprehensive dependency analysis is difficult for a variety of reasons, and it is easy for memory-unsafe dependencies to be overlooked.
First, languages often have multiple mechanisms for specifying or creating dependencies, which makes the identification process complex, and furthermore, it is computationally expensive, as sophisticated algorithms are required to track all potential interactions and side effects.
“Somewhere in the stack and dependency graph of every programming language, memory-unsafe code is written and executed,” the authors write.
look: Aqua Security Study Finds 1,400% Increase in Memory Attacks
“In many cases, these (memory-unsafe) languages have been widely adopted and used for many years, predating much of the recent activity attempting and encouraging a transition to memory-safe languages,” Hughes told TechRepublic. “Furthermore, there is a need for the broader development community to transition to more modern memory-safe languages.”
“It will be difficult to change many of these projects to a memory-safe language because refactoring/rewriting them to a memory-safe language would require resources and effort from the maintainers. The maintainers may not have expertise in memory-safe languages, and even if they did, they may not be motivated to do so since they are mostly unpaid volunteers who are not compensated for the projects they create and maintain.”
He added that organizations need to offer financial incentives and other resources to encourage open source developers to migrate their code, but also oversee any efforts to ensure that secure coding practices are implemented.
Recommendations for mitigating the risks of memory-unsafe code
The report states: The Case for CISA’s Memory Safety Roadmap Documentation and Technical Advisory Committee Memory Safety Report Recommendations on how to reduce the prevalence of memory-unsafe languages. These recommendations include:
- Migrate existing projects to memory-safe languages as recent advances have brought them to performance parity with non-memory-safe languages.
- Create a new project in a memory-safe language.
- Develop a memory-safe roadmap that includes a clear plan for integrating memory-safe programming into your system and addressing memory safety in your external dependencies.
- Manage external dependencies by ensuring that third-party libraries and components are also memory-safe or have mitigations in place.
- Train your developers in memory-safe languages.
- Prioritize security in software design from the beginning of the software lifecycle, including following Secure by Design principles.
Agency efforts to reduce the prevalence of memory-unsafe code
U.S. federal officials and researchers have been working in recent years to reduce the amount of memory-compromising software in circulation.
Ann October 2022 Report A Consumer Reports report noted that “approximately 60-70% of browser and kernel vulnerabilities, and security bugs found in C/C++ codebases, are due to memory safety flaws.” The National Security Agency then How software developers can protect against memory safety issues.
In 2023, CISA Director Jen Easterly called on universities to: Educating students about memory safety Secure coding practices. National Cybersecurity Strategy 2023 The implementation plan was then announced, Investing in memory-safe languages and Collaborating with the open source community In December of that year, CISA Memory Safe Roadmap Case Studies Technical Advisory Committee Memory Safety Report.
In February of this year, the White House released a report promoting the use of memory-safe languages and the development of software safety standards, which was backed by major technology companies such as SAP and Hewlett Packard Enterprise.
The U.S. government’s efforts are supported by a number of third-party organizations that share the goal of reducing the prevalence of memory-unsafe code. The OpenSSF Best Practices Working Group Special concern about memory safety In the subgroup, the Internet Security Research Group Prossimo Project The goal is to “migrate the Internet’s security-sensitive software infrastructure to memory-safe code.” Google OSS Fuzz A service that uses automated fuzzing techniques to continuously test open source software for memory safety vulnerabilities and other bugs.