Why Memory Isolation

You firmware is doing one thing. You don’t load unnecessary code into device. So why do you need to think about memory isolation? The only part of your firmware deserving protection are secrets for encrypted communication. Or, they are not?

There is this world of embedded devices which contain firmware written by single person, or maybe a small team. These devices are not connected to any kind of network, bus or radio. In this world, it is quite possible that you don’t need to think of memory isolation. Yet, this world is shrinking at rapid pace.

Contemporary embedded devices may think of memory isolation for multiple reasons which are outlined in this blog.

Mixed-criticality

Lets start with obvious case: Your device is doing something that is safety-relevant. Safety-relevant code is generally more expensive to R&D. Thus teams are searching ways how to split this code into multiple portions where some of the code won’t be safety-relevant anymore. This brings costs down as parts which cannot affect safety can be done with less rigor.

This brings another problem in: how will you ensure that the non-safety code in your firmware won’t affect integrity of the code in safety-relevant portion? This criterion is called freedom from interference and calls for measures that prevent low-critical code to affect highly-critical code in a negative manner.

To do so you need to provide a spatial and temporal isolation. Spatial isolation means that non-critical code won’t be able to access data of critical code and modify them in any way.

Here comes memory isolation: Putting critical and non-critical code into two isolation domains, you prevent one from interfering with another. Once isolation boundary is set, non-critical code cannot damage safety-relevant portion of memory and potentially affect safety of your device.

Supply-chain Sourced Bugs

In any moderately-large project it is a case that you have your software supply chain. It is not enonomically viable to write all your software from scratch anymore as this code is generic, repeating and usually large. Think of peripheral drivers, RTOSes and UI libraries which your device might use. You won’t write these from scratch for just one or two projects, will you?

This code might contain bugs despite the best effort of their autors to prevent them.

Isolating memory of these components from the rest of the system, you increase the resilience of your firmware against any possible bugs that may come from external code. While these bugs still can corrupt the faulty component, they cannot spread to other components and provide pretty much same level of freedom from interference guarantees as in the previous case.

Malicious or Broken Communication

If your device is connected in any way, there are some bad news for you. Internet is a dangerous place with automated scanners searching for vulnerabilities in connected devices. Here the topic is slightly connected with above as many stacks that provide connectivity are actually source from third party - be it USB, network, wireless of Bluetooth stack. Here the situation becomes even more critical as attacker does not need to be in a close proximity of your device in order to provide malicious input.

It turns out that wireless, bus and network stacks are a frequent source of vulnerabilities in all kinds of devices. Vulnerabilities in connectivity stacks can be exploited remotely.

If vulnerability is severe enough, then it can be used to read or even modify memory of your firmware in an unpredictable way.

Memory isolation can help to contain such exploitation. Of communication stack is isolated from the rest of the system, attacker can’t read memory outside this isolation domain nor modify it.

This case is even more severe, because instead of simply changing memory content, an attacker may try to exploit an existing vulnerability to run code that was never intended to run in your system. Whenever device allows communication with outer world, it is inevitable, that device contains data sent by the other side of the communication. One of the most severe vulnerabilities in existence as so-called remote code execution vulnerabilities which allow an attacker to execute such attacker-supplied data as if it was code.

Normally nothing in system prevents this. CPUs can execute code from RAM. You have probably already did that for one of legitimate reasons, such as speed or need to execute from RAM during flash updates. Yet there are cases where you clarly don’t want content of RAM being executed, such as if this content was supplied by a third party. Here memory isolation provides one strong aid: you can set some memory area as non-executable.

Such setting prevents an attacker from executing malicious data even if this data is stored within memory legitimately accessible by the vulnerable component. This makes firmware substantially more resilient against attacks and help maintaining integrity of your application.

Why Would Anyone Attack Me?

You still may ask: My device is not interesting to attackers, why would they attack it? It does not perform any sensitive control nor possess knowledge of important data. Should this matter to me?

Short answer is: Definitely.

The truth is, that in connected world, it doesn’t matter that much what information your device possess than whom it talks to! Even smart thermostat may become a valuable target of remote attack if it is connected to network which may contain assets worth stealing. Security of the whole network is as good as the security of the weakest elements connected. Quite often these weakest elements are IoT devices. They can serve as an entry point into network and enable attack from inside it. There, the level of trust is usually slightly higher than trust towards traffic coming from inside and thus makes attacker’s life easier.

So, while a smart thermostat may not be a valuable target, it may still serve as an entrypoint into network, where valuable assets are present, such as internet banking passwords. Attackers will chain multiple vulnerabilities and use your compromised device to attack some other device in the same network or to host a botnet.

This is no theory. Back in 2015 Charlie Miller and Chris Valasek used chaining of attacks to hack Jeep vehicles. They used publicly exposed telematic unit of contemporary Jeep cars to enter the local electrical system of the car. While telematic unit still could provide some valuable assets such as vehicle location, their primary target was elsewhere in the car.

Once the telematic unit was breached, it served as a platform to hack another piece of electronics in the car - the central gateway module. Once hacked, this provided full access to all the communication inside the car and allowed them to execute their final attack - to physically control the car movement by overriding inputs to brakes and steering.

Fortunately, Miller and Valasek weren’t malicious hackers. They are security researchers and they performed this highly visible hack basically in public to pursue Jeep to fix the vulnerability in telematic system which Jeep thought is not critical. They demonstrated it could be.

That’s why your device may become an interesting attack target if it doesn’t carry any important role on itself. It is important what it lives with in same network.

Summary

In the world of modern firmware, memory isolation makes sense in more scenarios than just to keep encryption secrets out of touch. Use of memory isolation will improve resilience of your firmware against bugs and attacks. Memory isolation serves as an additional layer of protection in Swiss-cheese model. Keeping things more secure than they need to be at first sight is actually good thing to do as your device may become the weakest link in the security chain, letting the attacker in. We expect you don’t want to be just the weakest link in the chain.