CISA warns about unsafe open source projects

'Most' projects are open memory corruption security flaws

CISA, the US Cybersecurity & Infrastructure Security Agency, has warned that the majority of critical open-source projects contain key memory-related security flaws.

In a new report [PDF] released this week, the Agency, together with counterpart organisations in Australia and Canada, examined 172 critical open source projects identified by the Open Source Security Foundation "to determine the extent to which they are written in memory-unsafe languages."

Memory-related software security flaws like buffer overflows offer an attack opportunity for adversaries, in some cases enabling them to take control of whole systems.

In its analysis, CISA found that 52% of the projects contain code written in a memory-unsafe language; with 55% of the total lines of code for all projects similarly compromised. It added: "Dependency analysis of three projects written in memory-safe languages demonstrated that each one depended on other components written in memory-unsafe languages."

Even those projects written in memory-safe languages potentially contain such vulnerabilities, the report added, due to external dependency on projects developed with less stringent security in mind.

Languages such as Rust, Golang, C#, Java and Python mitigate such security flaws by automatic garbage collection, reclaiming memory to prevent buffer overflows. Memory-unsafe languages expect programmers to make their own arrangements, although too many don't.

On the flipside, languages without built-in memory management mechanisms include C, C++, and Objective-C.

The report concluded: "We observed that many critical open source projects are partially written in memory-unsafe languages and limited dependency analysis indicates that projects inherit code written in memory-unsafe languages through dependencies.

"Where performance and resource constraints are critical factors, we have seen, and expect the continued use of, memory-unsafe languages. Examples include operating system kernels and drivers, cryptography, and networking, particularly in embedded applications.

"It may, however, be an effective security investment to transition these types of projects to memory safe languages, and new projects should also consider using memory safe languages. Recent advancements allow memory safe programming languages, such as Rust, to parallel the performance of memory-unsafe languages."

The report represents a follow-up to a report entitled The Case for Memory Safe Roadmaps [PDF], produced in association with a number of counterpart organisations, including the UK's National Cyber Security Centre.

This report was intended as a wake-up call to public and private sector organisations as cyber attacks, particularly led by nation states, continue to intensify.

"Previous attempts at solving the problem have made only partial gains, and today, two-thirds of reported vulnerabilities in memory unsafe programming languages still relate to memory issues," the report warned. It urged software company decision makers to take urgent action to expunge memory-unsafe languages and code from their products and services, with named executives tasked with the sole mission of getting it done.

Amanda Brock, CEO of OpenUK, told Computing, "Every time I hear anyone mention the words 'open source' and 'vulnerability' in the same sentence, I want to remind them that cybersecurity is a software issue, not an open source one. We need to better understand that all software can be vulnerable, and that in our digital age it's going to be necessary to manage open source vulnerabilities to enable access to the best digital infrastructure and innovation. The benefits and the risk need to be assessed.

"For years there have been many great technical and governance people working to make sure that open source meets levels of compliance requested by commercial users, and what I'd like to see today is that proprietary software meets these standards too. In this way, at least, we need a shift in thinking so that we manage all software. That's an issue for the business users who recycle and reuse open source, and not for the individual developers or open source communities we see contributing. Laws need to get better at making these distinctions too. The CRA in the EU has not achieved this."