A comprehensive new study has unearthed fresh details on the extensive and troubling use of memory-unsafe code in major open source software projects.
The chances that fresh insight on a long known issue will spur any immediate changes to the software landscape remain bleak, given just how enormous, costly, and complex the task is of rewriting codebases entirely in memory-safe code.
Memory-unsafe programming languages such as C and C++ allow programmers to have more direct control over memory-related functions in code, which can often lead to very common application security issues like buffer overflows and use-after-free errors.
Such flaws represent a large proportion of all vulnerabilities in modern application software.
In contrast, memory-safe languages - the most common examples of which include Rust, Python, Java, and Go -offer guardrails such as built-in runtime and compile time checks to mitigate against common memory related errors.
Most OSS Projects Contain Memory-Unsafe Code The US Cybersecurity and Infrastructure Security Agency along with the FBI and counterparts at the Australian Cyber Security Centre and the Canadian Centre for Cyber Security this week released a report summarizing the results of their investigation into the use of memory-unsafe code in OSS. The findings, while troubling, are not entirely unexpected given past data on the extensive use of memory-unsafe languages in almost all modern codebases.
Fifty-two percent of the 172 major open source projects that the research authors looked at contained code written in a memory-unsafe language.
More than half of the total lines of code in all the projects combined were written in a memory-unsafe language, with the larger projects being the worst culprits.
Some 95% of the total lines of code in Linux for instance are memory-unsafe.
For MySQL Server, that number was 84%; for TensorFlow it was 64%; for Zephyr 84%; and for Chromium 51%. On average, 26% of the total lines of code in the 10 largest open source projects consisted of memory-unsafe code.
Even projects written in memory-safe languages were at risk from dependencies on unsafe components.
The tendency - and often the need - to disable memory-safety features to accommodate functional requirements in applications can often neutralize the benefits of using otherwise memory-safe languages.
CISA Consistent With Previous OSS Data The findings are consistent with numerous previous studies that have examined the extensive problems tied to the use of memory-unsafe languages.
The most recent is a February 2024 technical report from the White House that urged industry stakeholders to go back to the building blocks and start over with using memory safe code in all software.
In 2022, the US National Security Agency urged software makers and all organizations developing software to consider adopting memory-safe languages to reduce risk from memory management related software issues in modern code bases.
The continued pounding away at the topic over the years has spurred some change, but most expect it will take years - if not even decades - for a whole scale shift to memory-safe languages to happen.
Making the World Memory-Safe: A Huge & Complex Challenge Omkhar Arasaratnam, general manager at OpenSSF says memory safety issues aren't specifically a problem for either open or closed-source software.
As newer projects adopt memory-safe languages, expect the use of memory-unsafe languages to decrease over time, in all but niche applications.
Tim Mackey, head of software supply chain risk strategy at Synopsys Software Integrity Group, says the new report does a good job showing how some major open source software projects such as Kubernetes and WordPress are authored in a memory-safe language.
It would be interesting to know if memory-safe languages are being used in new projects on GitHub, and whether memory-safe libraries are being used as dependencies in larger projects.
This Cyber News was published on www.darkreading.com. Publication date: Fri, 28 Jun 2024 17:25:08 +0000