A report by the US Cybersecurity and Infrastructure Security Agency found that more than half of open source projects contain code written in a memory-unsafe language. Memory-unsafe means that the code allows operations that can corrupt memory, leading to vulnerabilities such as buffer overflows, use-after-free, and memory leaks.
The results of the report, published jointly with the FBI, the Australian Signals Directorate’s Australian Cyber Security Centre, and the Canadian Cyber Security Centre, are based on an analysis of 172 critical projects as defined by OpenSSF’s Critical Projects Security Working Group.
55% of the total lines of code for these projects were written in a memory-unsafe language, while the larger projects had even more lines. More than a quarter of all 10 largest projects in the data set have memory-unsafe lines, while the average ratio among them is 62.5%. Four of them are composed of more than 94% memory-unsafe code.
What are memory-unsafe languages?
Contents
Memory-unsafe languages, such as C and C++, require developers to manually enforce strict memory management practices, including careful allocation and deallocation of memory. Naturally, mistakes will occur, and this will result in vulnerabilities that can allow adversaries to take control of software, systems, and data.
On the other hand, memory-safe languages, such as Python, Java, C#, and Rust, handle memory management automatically through built-in features and shift the responsibility to the interpreter or compiler.
Look: 10 Best Python Courses Worth Taking in 2024
The report’s authors wrote: “Memory security vulnerabilities are among the most prevalent classes of software vulnerabilities and generate substantial costs related to patching, incident response, and other efforts for both software manufacturers and consumers.”
They also analyzed software dependencies on three projects written in memory-safe languages, and found that each of them depended on other components written in memory-unsafe languages.
“Thus, we found that memory safety vulnerabilities are present in most of the significant open source projects analyzed, even those written in memory-safe languages,” the authors wrote.
Chris Hughes, chief security consultant at open source security company Endor Labs and a cyber innovation fellow at CISA, told TechRepublic: “When we look at annual exploitation across different classes of vulnerabilities, the findings certainly pose a risk to both commercial organizations and government agencies, as vulnerabilities in this class are widely exploited. They are often among the most exploited vulnerabilities year after year.”
Why is memory-unsafe code so prevalent?
Memory-unsafe code is prevalent because it gives developers the ability to directly manipulate hardware and memory. This is useful in cases where performance and resource constraints are critical factors, such as operating system kernels and drivers, cryptography, and networking for embedded applications. The authors of the report noticed this and expect it to continue.
Developers may use memory-unsafe languages directly because they are unaware of the risks or do not care about them. They may also intentionally disable memory-safe features of a memory-safe language.
However, those who are aware of the risks and who do not wish to include memory-unsafe code may inadvertently do so through dependencies on an external project. Performing comprehensive dependency analysis is challenging for several reasons, making it easy for memory-unsafe dependencies to slip through the cracks.
For one thing, languages often have multiple mechanisms for specifying or creating dependencies, complicating the identification process. Moreover, doing so is computationally expensive, since sophisticated algorithms are needed to track all possible interactions and side effects.
“Somewhere down every programming language stack and dependency graph, memory-unsafe code is written and executed,” the authors wrote.
Look: Aqua Security study finds 1,400% increase in memory attacks
Hughes told TechRepublic: “Often, these (memory-unsafe) languages have been widely adopted and used for years before recent activity to encourage a shift to memory safe languages. Additionally, the broader development community requires a shift to more modern memory safe languages.”
“Many of these projects would be difficult to convert to memory safe languages as it would require resources and effort from maintainers to refactor/rewrite into memory safe languages. Maintainers may not have expertise in a memory safe language and, even if they did, they may not be incentivized to do so, as they are largely unpaid volunteers who are not remunerated for the projects they create and maintain.”
He said organizations should provide monetary incentives and other resources to encourage open-source developers to make changes to their code, but should also monitor any efforts to ensure that secure coding practices are being implemented.
Recommendations for reducing the risk of memory-unsafe code
The report cites CISA’s The Case for Memory Safe Roadmap document and the Technical Advisory Council on Memory Safety report for recommendations on ways to reduce the prevalence of memory-unsafe languages. These recommendations include:
- Convert existing projects to memory-safe languages, as recent advances mean they now parallel the performance of memory-unsafe languages.
- Write new projects in memory-safe languages.
- Create a memory-safe roadmap that includes clear plans for integrating memory-safe programming into the system and addressing memory safety in external dependencies.
- Manage external dependencies by ensuring that third-party libraries and components are also memory-safe or have mitigation measures in place.
- Train developers in memory-safe languages.
- Prioritize security in software design from the beginning of the software lifecycle, such as by following secure by design principles.
In recent years federal officials and researchers in the US have been working to reduce the amount of memory-insecure software in circulation.
An October 2022 report from Consumer Reports states that “about 60 to 70 percent of browser and kernel vulnerabilities — and security flaws found in C/C++ code bases — are caused by memory insecurity.” Then, the National Security Agency released guidance for how software developers can protect themselves from memory-security problems.
In 2023, CISA director Jane Easterly called on universities to educate students about memory safety and secure coding practices. The 2023 National Cybersecurity Strategy and its implementation plan were then published, discussing investing in memory-safe languages and collaborating with the open source community to advance them. That December, CISA published The Case for Memory Safe Roadmaps and the Technical Advisory Council’s report on Memory Safety.
In February this year, the White House published a report promoting the use of memory-safe languages and the development of software security standards, which was supported by major technology companies including SAP and Hewlett Packard Enterprise.
The US government’s efforts are being supported by a number of third-party groups that share its objective of reducing the prevalence of memory-unsafe code. The OpenSSF Best Practices Working Group has a dedicated Memory-Safety Special Interest Subgroup, while the Internet Security Research Group’s Proximo project seeks to “move the Internet’s security-sensitive software infrastructure to memory safe code.” Google has developed the OSS-Fuzz service which continuously tests open-source software for memory-safety vulnerabilities and other bugs using automated fuzzing techniques.
#CISA #report #finds #opensource #projects #memoryunsafe #code