Why Memory Safety Should Be a Top Priority

“Memory safety is a thing”

I’ve uttered these words increasingly in recent years, often during my opening remarks at the IoTSF Annual Conference and I’ll keep saying them until memory safety is not such a big deal to be concerned about.

So what’s the big deal?

Two key trends of the past twenty years that I also highlight are the increasing levels of connectivity and software-defined products (i.e. embedding processors into many products) – giving birth to the term ‘the Internet of Things’. IoT is great for innovations in productivity, efficiency and new products and services. Yet, software is eminently hackable, and connectivity makes us significantly more vulnerable to remote attacks. Needless to say, but hackability and vulnerability are not a good combination for anyone other than the malevolent.

For decades, memory-safety vulnerabilities have been a major security challenge;  approximately two-thirds of all critical security vulnerabilities in software can be traced back to memory-safety issues. Read that again ‘two-thirds’. Addressing the memory safety challenge would not only manifest in sizable commercial and economic gains, it would also mean fewer of those cumbersome – but important – software updates.

Pervasive and persistent threat

Practically speaking, memory safety is a critical aspect of software development that ensures programs operate reliably and securely by preventing unauthorised access to memory systems. Common issues include buffer overflows, overreads, page faults, leaks and unwanted aliasing. Memory-safe systems guarantee that software cannot interact with or modify memory in ways that might result in errors or vulnerabilities. The systems we have deployed, and continue to deploy, rely on vast amounts of legacy C/C++ code that’s impossible to replace entirely. Even languages like Java, JavaScript, and Python often rely on C and C++. When combined with network vulnerabilities, attackers can exploit memory-safety issues to gain complete control of a system. While we’ve developed mitigation techniques, attackers continue to adapt. Despite countless hours of code review and investments in analysis tools, the rate of these vulnerabilities remains stubbornly consistent – that is, we have a pervasive and persistent threat – a never-ending arms race between defenders and attackers.

It is not all bad news however, as strong memory safety mitigations can prevent a wide range of attacks with technologies generally falling into four categories:

• Memory-safe and type-safe languages: Languages like Rust, Python, Swift, Java, C#, and SPARK offer built-in protections.
• Formal methods: These provide mathematically sound verification of memory safety.
• Hardware memory protection: Systems can detect memory-safety violations as they occur.
• Software fault isolation and software compartmentalisation: These systems limit the damage (‘blast radius’) from successful attacks.

At IoTSF, we’ve actively supported the UK Government’s Digital Security by Design (DSbD) programme as it aligns strongly with our mission to ‘make it safe to connect’ by fixing the foundations of computing. The DSbD programme has driven the development of the CHERI (Capability Enhanced RISC Instructions) technology, which provides memory protection and compartmentalisation native to the hardware. With the current funding concluding, DSbD has made a significant contribution by leading awareness to socialise the problem and eulogising the solutions space at a global level.

And closer to home, we’ve worked with our members across the TechWorks connected-communities on collaborative projects – notably the Secure Networking by Design (Routers) and RESAuto (braking systems) projects to demonstrate the real-world efficacy of the CHERI technology.

Progress continues as a result, and we’re hearing increasing calls from governments, academia, and even within our ranks to embrace memory-safety technologies as part of a broader “Secure by Design” approach. Prominent players are also actively discussing the prospect of memory-safety standardisation as it is widely regarded as an essential step to ensure more software is secure for everyone.

In order to specify memory-safety requirements, a common, technology-neutral language and framework is needed. This would allow for the reliable design, implementation, auditing, and procurement of strongly memory-safe systems. Without this shared understanding, it’s tough to fully appreciate the benefits and address the market failures that hinder the adoption of these vital technologies. Standardisation will also pave the way for improved industry best practices – a theme at the very heart of the IoTSF programme.

While the potential of universal strong memory safety is exciting, achieving it requires a significant shift in how we approach software development. Many in the industry currently lack the economic incentive to change, and adopting new technologies can involve costs and require a reallocation of engineering resources. Often, there’s a perception of limited demand for enhanced security features, leading to the prioritisation of more immediately visible customer demands. However, this perspective overlooks the broader economic picture. Society bears the brunt of memory-safety vulnerabilities, and the costs associated with breaches, disaster recovery, and national security implications are substantial.

One key issue is that customers often can’t fully appreciate or articulate the value of strong memory safety, and they may lack confidence in vendors’ ability to deliver it. Standardisation can also help here. By establishing clear, technology-neutral requirements for memory safety, we can bridge this gap and enable informed decision-making during procurement.

Standardising memory safety involves several key steps:

• Incorporating existing, weaker protection technologies into a broader framework
• Focusing on approaches that are technology and vendor-neutral
• Clearly defining the line between established practices and ongoing research
• Creating tiered safety assurance levels to guide technology selection
• Offering specific guidance for both new and existing systems

In doing this, we can advance from a probabilistic set of mitigations towards a complete and deterministic future.

Achieving widespread memory safety is therefore a marathon, not a sprint, requiring ongoing deployment of new hardware, software, and formal techniques. To get there, we need a clear, industry-wide definition of memory safety, coupled with improved engineering practices. By standardising memory safety, we enable better design and procurement, ensure systems are tailored to specific requirements, and make implementations auditable.

It will also take many players with the will, determination and resources to see it through – it is possible and the article above is a well thought through blue print and roadmap (hint: if you’ve got this far I encourage you to click on the image and read it – it’s time well invested).

In complete partnership with our members, the IoT Security Foundation will continue to play its part as champion, practitioner, influencer and – at times – critical friend in the pursuit of ever-better security. We’re fully behind the rallying cry for standardisation. On a more personal note, I look forward to the time when we can collectively say ‘memory safety? Oh yeah, that used to be a thing’.

John Moor

Managing Director, IoT Security Foundation

Read our Marketing Report for a CHERI-based Router