By Deb Radcliff, industry analyst and editor of CodeSecure’s TalkSecure educational blogs and podcasts (syndicated at Security Boulevard, YouTube, and Bright Talk).
Memory leakage vulnerabilities have persisted for decades, dating back at least to the Morris Worm in 1988. So pervasive is this threat to the national infrastructure, that the White House issued a ONCD technical report in February suggesting that developers of embedded systems stop using C and C++ languages and replace their code bases with “memory safe” languages such as Rust.
The government is right to be worried. There are more than 1500 documented records of memory leak vulnerabilities at MITRE’s Common Vulnerabilities and Exchange (CVE) listing. Memory leaks can lead to a host of different problems for embedded systems. Memory leaks can result in system outage (denial of service), leaking of data, corrupting of data, system crashes, task hijacking, installation of ransomware, and many more security and safety issues.
But don’t expect C and C++ to be swapped out anytime soon, because that would involve replacing trillions of lines of vetted, trusted code with newer programming languages that have not benefited from the decades of use, refinements, and best practices guidelines that C and C++ have.
What is Memory-Safe?
The report specifically points to Rust as the most viable alternative to C and C++. Rust, by default, prevents unintended memory leakage through several built-in features, according to a blog by Jacob Beningo, an embedded software consultant who specializes in real-time microcontrollers. These include immutable variable settings; “borrowing” (in which the compiler assigns ownership to each variable); and bounds-checking access against an assigned array or memory location.
Other languages may fall into the memory-safe category, such as C#, Go, and Java, but their memory restrictions vary and, and, as DataBreachToday stated, are ‘no panacea.’
For example, Beningo also wrote that “Rust can be just as unsafe as other programming languages.” He calls out Rust’s “unsafe” programming mode that developers can switch to when Rust’s default memory safety controls are too restrictive. Commonly, developers use unsafe mode when integrating Rust into C-written legacy programs. Beningo also cites how difficult it is to learn and master Rust, as well as challenges in getting code to compile securely because of restrictions.
C is Foundational
C was first introduced in 1972 and C++ was first released in 1983. C++ has many features that make programming easier, more secure, and safer having been vetted over time. However, the C++ runtime model is more complex, and that complexity requires validation during testing, especially if functional safety is a requirement (such as with Industrial, medical, aviation, and transportation systems with standards such as IEC 61508, IEC 62304, DO178, EN50128).
“The ONCD report mainly talks about security. Security is key, but safety is related to security. You can have security without safety, but you cannot have safety without security. For a lot of embedded systems like those in aviation, medical, and transportation, safety is also related,” says Mark Hermeling, VP of Global Solutions Engineering at CodeSecure.
Over more than 40 years, C and C++ have proven themselves as ideal coding languages for embedded systems where code needs to be light, agile, and efficient due to limited processing space and time. It would be impractical if not impossible to phase such programs out any time soon given how ubiquitous they are. The ONCD report itself states—and industry pundits agree—that replacing trillions of lines of vetted legacy code will be difficult, if not possible, even with a growing body of automated porting tools coming to market.
“There is a metric bucket load of software written in C and C++ already out there. And it goes beyond the software … The toolchains would need to change as well. From Real-Time Operating Systems upwards to compilers, middleware, application layers, and frameworks—they’d all have to include support for these new languages. And that will take time,” Hermeling notes.
Shifting Left with SAST
Irrespective of the coding language being used, development organizations need to start left at planning. This includes determining what language meets their product, integration, safety, and security requirements before writing any code. Once applications are under development, SAST (Static Application Security Testing, which is also known as static analysis testing) can support secure coding practices, including detecting memory leak vulnerabilities, when integrated into the CI/CD pipeline.
Shifting security left in the development cycle is strongly recommended in the ONCD report, which advises product companies to:
- Deploy “static analysis to scan software for specific properties without executing the code.”
- Cross-check results with assertion-based testing.
- Integrate security into developer toolchains.
- And use formally verified code components from secure libraries.
Advanced static analysis tools for C and C++ can often be extended to include domain-specific resources by implementing company, or domain-specific validation logic. For example, “Use-After-Free” bugs are a class of nasty memory errors that occur because the programmer has accessed a block of memory after it has been freed. If the memory allocator has re-used that block, then it may contain unrelated data. “The symptoms can be mysterious so these can be hard to diagnose and fix. Symptoms could be anything from a crash to leakage of data, which can often lead to a security vulnerability,” Hermeling notes. “Advanced SAST tools recognize these and mitigate them.”
Metrics = Software Measurability = SBOMs
The ONCD report on memory-safe languages evolved out of the government’s Secure-by-Design policies aimed at technology manufacturers and supported by CISA (Cybersecurity and Infrastructure Security Agency under DHS). As such, the report also calls for vendors to provide metrics, referred to as “software measurability.” It states that “The way coders do their work is of critical importance to the national interest.” But the report falls short of calling for Software Bills of Materials – SBOMs – which the CISA is also driving. SBOMs are ingredient lists of software components and known vulnerabilities therein.
Ultimately, the White House report focuses on “the highest leverage method to reduce memory safety issues” (aka the programming languages rather than mitigating controls) to reduce the risk to software-driven hardware devices. It’s overall takeaways:
- Apply memory-safe languages to new products and migrate old products to memory-safe code.
- Follow roadmaps for memory-safe language replacement.
- Using spacecraft as its use case, it also recommends caution when shifting to Rust. It states that C and C++ meet all space system prerequisites except for memory safety. On the other hand, Rust meets all requirements including safety but is not as vetted and proven in space systems as C/C++ are.
Updating the Hardware
On a final solution point, the ONCD memory leakage report touches on memory-safe hardware, where the chips flag memory safety violations and can change how software accesses memory. For example, memory-safe hardware for OT/IOT designed to run C and C++ languages safely is already in the works. In a recent video interview, John Goodacre, director of the UK Government’s Digital Security by Design (DSbD) initiative, explains. “We’re changing the instructions that a computer uses to run software.”
The initiative includes building and delivering memory-safe hardware that uses CHERI (Capability Hardware Enhanced RISC Instructions) and is designed to prevent unsafe C or C++ patterns from running. The initiative also includes preparing training for the hardware and bolstering required tools to perform software changes in the least intrusive way.
Left and Right
Shifting security left into the developer workflow reduces memory leak vulnerabilities. But, as the ONCD report suggests, security also needs to be on the right with mitigating controls, whether that be new secure chips, application firewalls or other traditional protections.
As the report surmises, “The CISO using the software cannot be the only stakeholder in securing the software.” It specifically calls out the responsibility of the CTO’s (Chief Technology Officers) at the manufacturers building the software. It doesn’t use the title of software product security officers, but their responsibilities for software products are similar.
Resource:
Challenges with C languages in MISRA-Compliant embedded applications
Advanced static analysis for C and C++ and the impact of memory Leaks on programs and resources (including other dynamically allocated resources such as file descriptors, graphics handles, and network connections.
