Page 52 - EE Times Europe Magazine – June 2024

52 EE|Times EUROPE

THE INDUSTRY
Is C/C++ Memory-Safe?

By Robert Huntley

The half-century-old programming language is showing its security vulnerabilities, but
swapping out the embedded community’s common tongue for an alternative like Rust

would not be straightforward.

ith cybersecurity high on everyone’s to-do list, it is no Poor coding practices and limited code testing can result in embedded
surprise that the question of memory-safe embedded sys- systems with security vulnerabilities. There’s an argument to be made,
tems keeps popping up. The Biden-Harris administration however, that with improved attention to coding standards, more
Whas been particularly vocal on this topic, sounding the extensive testing, and application of static and dynamic code analysis
alarm in 2021 and again in early 2024. Its latest communication, titled tools, there may be no need to suffer the trauma of a language change.
“Back To The Building Blocks: A Path Toward Secure and Measurable
Software,” highlights the increasing number of memory-safety vulnera- WHAT MAKES C MEMORY-UNSAFE?
bilities and recommends that developers swap out memory-unsafe Buffer overflows and poor memory management routines are the most
languages, notably C and C++, for memory-safe alternatives. obvious and frequently exploited vulnerabilities. An overflow, such as
According to the U.S. National Security Agency (NSA), memory-safe when an application accesses an array outside its defined bounds, is
languages include C#, Go, Java, Ruby, Rust and Swift. In collaboration easy to replicate. An adversary with sufficient skills can use the result-
with partners, the NSA has published a guidance document for top- ing memory failure to inject malicious code.
level executives to assist in eliminating memory-safety vulnerabilities The code in Figure 1 dimensions an array, ary, with five elements
from their companies’ products. and writes an index counter to each element. The readback, however,
An often-quoted research statistic on memory-safety common reads back one element beyond the sized array (Figure 2). The code
vulnerability exposures (CVEs) comes from Microsoft, which found
that memory-safety issues accounted for more than 70% of CVEs from
2006 to 2018. Although the report covers only Microsoft C/C++-based
products and not embedded systems, it highlights the extent of the
cybersecurity challenge.
C DOMINATES EMBEDDED DEVELOPMENT
Written in the early days of the UNIX operating system for Digital
Equipment’s PDP-11, C has been around for more than half a century.
Though it took a while for it to gain popularity among the embedded
development community, C/C++ dominates the embedded landscape
today. Computer scientists Brian W. Kernighan and Dennis M. Ritchie—
the latter created the language in 1972 at Bell Labs—described C as a
“general-purpose program-
There is no doubt ming language which features
economy of expression,
about the need for modern control flow, data
memory safety in an structures and a rich set of Figure 1: Example C code that reads beyond the boundaries of an
operators.” Performance was
1
embedded system, undoubtedly a key consider- array (Source: Robert Huntley)
ation, but the initial goals for
but the implications the language had little to do
and ramifications of with security.
There is no doubt about
switching to another the need for memory safety in
an embedded system, but the
language are dramatic. implications and ramifica-
tions of switching to another
language are dramatic. The
embedded systems community has lived and breathed C/C++ for
decades. It is ingrained in the fabric of the industry, from silicon ven-
dors to toolchain suppliers, RTOS providers, code libraries and more.
Changing to another language would require a concerted effort across
the embedded community, involving extensive retraining programs
and considerable cost.
At the heart of memory safety is the requirement for a language with
built-in memory-safety features and capabilities so that the security Figure 2: The results from running the code, highlighting the
burden does not fall squarely on the developer, as is the case today. arbitrary data (Source: Robert Huntley)

JUNE 2024 | www.eetimes.eu