In the United States, the federal CISA (Cybersecurity and Infrastructure Security Agency), with the US Federal Bureau of Investigation (FBI), Australian Signals Directorateโs Australian Cyber Security Centre, and Canadian Cyber Security Center, has brought out joint guidance on the scale of memory safety risk in selected open source software (OSS).
CISA says it encourages all software manufacturers to review the methodology and results in the guidance to:
Reduce memory safety vulnerabilities;
Make secure and informed choices;
Understand the memory-unsafety risk in OSS;
Evaluate approaches to reducing this risk; and
Continue efforts to drive risk-reducing action by software manufacturers.
The authorities state that ‘memory safety vulnerabilities are among the most prevalent classes of software vulnerability and generate substantial costs for both software manufacturers and consumers related to patching, incident response’ and other cyber work. It’s recommended that software firms create memory safe roadmaps, including plans to address memory safety in external dependencies, which commonly include open source software.
This latest guidance covers some 172 projects derived from the Open Source Security Foundation (OpenSSF) Securing Critical Projects Working Groupโs List of Critical Projects. The researchers found that about half, 52 per cent of the projects contain code written in a memory-unsafe language; that 55pc of the total lines of code (LoC) for all projects were written in a memory-unsafe language; and that ‘the largest projects are disproportionately written in memory-unsafe languages’.
To read the 22-page report, visit the CISA website.
Comment
Gunnar Braun, technical manager at the Synopsys Software Integrity Group, said: โIt is important to raise awareness about the critical role of memory-safe languages in making our world more secure. Memory safety should be one of the key considerations when deciding on a programming language. The report and its preceding ‘Case for Memory Safe Roadmaps’ bring this to C-level executives – where it belongs. Software security and safety are no longer a purely technical concern.
โIt is interesting that most of the 172 projects discussed in the report are among the most mature and robust pieces of software in our world, for example, OpenSSL, musl, glibc, or arm-trusted-firmware. As stated in the report, many of these programs are targeted for embedded systems with strict resource and performance constraints. If changing the programming language is not possible, static code analysis and fuzzing tools are essential to produce software that it is literally part of almost every electronic device we use.
โFortunately, the industry has developed extremely powerful static code analysers over the last couple of decades, using advanced program analysis to detect memory flaws in even huge, complex code bases such as the Linux kernel. These tools are expensive but go lightyears beyond what the common open-source, rule-based checkers and linters can do. The most advanced tools even detect concurrency issues, such as race conditions, and can detect the absence of mitigation techniques in modern compilers, such as Data Execution Prevention (DEP) or Buffer Security Check. All of these projects use the best static code analysis tools in the market for many years, and often not just one.
โSome memory-safe languages, such as Rust or Go, are already making their way into embedded systems, so I’m optimistic that C/C++ will be largely replaced one day – but not today, and not tomorrow. Until we get there, static code analysis and fuzzing tools will be as important as they always were, if not more.โ
