According to a report from the United States’ Cybersecurity and Infrastructure Security Agency, a majority of open-source projects harbor code crafted in a memory-unsound language. Memory-unsound denotes that the code enables operations that could corrupt memory, potentially resulting in vulnerabilities such as buffer overflows, use-after-free, and memory leaks.
Collaborated with the FBI, Australian Signals Directorate’s Australian Cyber Security Centre, and Canadian Cyber Security Center, the report’s findings stem from an evaluation of 172 crucial projects categorized by the OpenSSF’s Securing Critical Projects working group.
From the collective lines of code in these projects, 55% were scripted in a memory-unsound language, with larger projects exhibiting more instances. Memory-unsound lines comprise over a quarter of all the top 10 projects in the dataset, while the median ratio among them stands at 62.5%. Four projects consist of over 94% memory-unsound code.
What are memory-unsound languages?
Languages deemed memory-unsound, such as C and C++, necessitate developers to manually execute stringent memory management practices, encompassing meticulous allocation and deallocation of memory. Naturally, errors are inevitable, leading to vulnerabilities that may empower adversaries to seize control of software, systems, and data.
In contrast, memory-safe languages like Python, Java, C#, and Rust automate memory management through intrinsic features, shifting the responsibility to the interpreter or compiler.
SEE: The 10 Best Python Courses Worth Taking in 2024
The report’s authors asserted, “Memory safety vulnerabilities rank among the most prominent classes of software vulnerability and incur significant costs for software producers and consumers concerning patching, incident response, and other endeavors.”
They also scrutinized the software dependencies within three projects formulated in memory-safe languages and discovered that each relied on other components scripted in memory-unsound languages.
“Therefore, we conclude that a major portion of the critical open-source projects analyzed, even those penned in memory-safe languages, potentially harbor memory safety vulnerabilities,” the authors penned.
Chris Hughes, the principal security consultant at the open-source security enterprise Endor Labs and cyber innovation fellow at CISA, disclosed to TechRepublic, “The discoveries indeed pose a threat to both corporate entities and government agencies due to the prevalent exploitation of this category of vulnerabilities when examining the annual exploitation among vulnerability categories. They frequently stand as among the most frequently exploited category of vulnerabilities year-on-year.”
Why is memory-unsound code so widespread?
Memory-unsound code proliferates as it empowers developers to directly maneuver hardware and memory. This proves advantageous in scenarios where performance and resource restrictions play decisive roles, as in operating system kernels and drivers, cryptography and networking for embedded applications. The report’s authors noted this trend and anticipate its perpetuation.
Developers may opt for memory-unsound languages inadvertently due to lack of awareness or carelessness about the risks. They can also purposefully deactivate the memory-safe features of a memory-safe language.
However, individuals cognizant of the risks and unwilling to integrate memory-unsound code might unwittingly do so via a reliance on an external project. Conducting a comprehensive dependency analysis proves challenging for various reasons, allowing memory-unsound dependencies to slip through undetected.
Primarily, languages encompass multiple mechanisms for specifying or creating dependencies, complicating the identification process. Moreover, the computation costs are exorbitant since advanced algorithms are essential to track all potential interactions and side effects.
SEE: Aqua Security Study Finds 1,400% Increase in Memory Attacks
Hughes conveyed to TechRepublic, “Frequently, these (memory-unsound) languages have been extensively embraced and utilized for years before the recent endeavors to promote the shift to memory-safe languages. Additionally, there exists a necessity for the broader developer community to transition towards more contemporary memory-safe languages.
“Transitioning numerous projects to memory-safe languages proves challenging as it demands resources and efforts from the maintainers to refactor/rewrite in memory-safe languages. The maintainers might lack expertise in the memory-safe language, and even if they possess it, they might lack the incentive to proceed, given that they are majorly unpaid volunteers not compensated for the projects they conceive and maintain.”
He pointed out that organizations should tender monetary incentives and other resources to prompt open-source developers to switch their code while simultaneously ensuring vigilant monitoring to enforce secure coding practices.
Strategies to minimize risks of memory-unsound code
The report cites recommendations from CISA’s The Case for Memory Safe Roadmaps document and the Technical Advisory Council’s report on memory safety to curtail the prevalence of memory-unsound languages. These suggestions encompass:
- Migrate existing projects to memory-safe languages, given recent advancements matching the performance of memory-unsound languages.
- Craft new projects using memory-safe languages.
- Construct memory-safe roadmaps incorporating definitive plans for assimilating memory-safe programming into systems and addressing memory safety in external dependencies.
- Oversee external dependencies by certifying that third-party libraries and components are either memory-safe or have countermeasures in place.
- Educate developers on memory-safe languages.
- Accentuate security in software design right from the onset of the software lifecycle, such as by embracing Secure by Design principles.
Initiatives from officials to dwindle pervasiveness of memory-unsound code
Government officials and scholars in the United States are diligently collaborating.to minimize the prevalence of memory-unsafe programs being disseminated lately.
A report from Consumer Reports in October 2022 highlighted that “around 60 to 70 percent of vulnerabilities in browsers and kernels, as well as security flaws detected in C/C++ code bases, arise from memory unsafety.” Subsequently, the National Security Agency issued guidance on protective measures against memory-safety concerns for software developers.
In 2023, Jen Easterly, Director of CISA, urged universities to educate students about memory safety and sound coding techniques. The National Cybersecurity Strategy of 2023 and its action plan were subsequently released, focusing on investments in memory-secure languages while joining hands with the open source community for their advancement. That December, CISA issued The Case for Memory Safe Roadmaps and the Technical Advisory Council’s findings on memory safety.
In February of this year, the White House released a publication endorsing the usage of memory-protected languages and the establishment of software safety norms, supported by key tech corporations such as SAP and Hewlett Packard Enterprise.
The endeavors of the U.S. government are being bolstered by various external organizations that share their mission of curbing the proliferation of memory-insecure code. The OpenSSF Best Practices Working Group includes a specialized Memory-Safety Special Interest sub-segment, while the Prossimo initiative by the Internet Security Research Group aims to convert the Internet’s security-centric software infrastructure to memory-safe code. Google has introduced the OSS-Fuzz service for continuous assessment of memory-safety vulnerabilities and other bugs in open-source software using automated fuzzing methodologies.
About Author
