Meltdown and Spectre: The Impact of Processor Bugs on IoT Security

An Introduction

System security has normally been seen as an issue relevant only to the realms of IT, from corporates down to the desktop, and not often considered seriously within the embedded sphere. This is rapidly changing, due to the explosion of the Internet of Things (IoT) and the increasing importance of embedded systems in safety-critical applications. This was brought home last year with the Mirai malware, that infected digital video recorders and other low level but internet connected devices. It did this, not for any aspect of their specific functions, which continued unhindered, but firstly to identify and infect other devices and then to use large numbers of infected devices as the launch pads for Distributed Denial of Service attacks that closed down or dramatically slowed down web host sites. Since many of these recorders, and their linked cameras, were often part of security systems, it does not require much imagination to see infecting them could have been used for other purposes. Mirai flourished, and variants continue to flourish, because millions of devices are shipped with default security settings which are pretty much an open door to an inquisitive piece of malware.

While Mirai used the Internet and Internet Protocol to enter the targeted devices, other communication channels can also be used, such as Bluetooth. IoT security specialist Armis has identified eight vulnerabilities in the Bluetooth stacks that handle communication in many mobile devices. They call these BlueBorne and a discussion of these is the subject of another IoT security paper “Bluetooth’s battle with the hackers heats up.”

It is becoming evident that hackers are no longer just socially maladjusted young men working from their bedrooms but organised groups with great technical sophistication. Some of these may be criminal groups, while others are national entities – it is widely accepted that Russia is using a range of different cyberweapons against the Ukraine, including closing down the electrical transmission grid. Much of the work has concentrated on the weaknesses in software and in human frailty. But these organised groups are turning their attention to the IoT and the Industrial Internet of Things, where data gathering and transmission, often without any human intervention, can provide valuable information about an organisation’s activities that can be exploited for commercial gain, or can be corrupted to cause serious damage, physically through causing equipment to run outside the specification, and financially by disrupting the organisations operations.

And it is this that makes the discovery of the two hardware vulnerabilities, Meltdown and Spectre especially worrying.

Meltdown and Spectre

What are Meltdown and Spectre?

Most of the security issues that organisations face today rely on exploiting aspects of weakness in the software of a system. There are also attack methods that use information gathered from the physical implementation of a system. These side-channel attacks gather, for example, timing information, power consumption, or electromagnetic leaks to build understanding of what the system under investigation is doing. Meltdown and Spectre go beyond that to exploit aspects of the design of high performance processors to gain access to information from the running applications. These design features are used in many modern Intel and AMD processors and Arm cores and are caching and speculative execution.

A simple pseudo program might be:

• t = a+b
• u = c+d
• v = e+f
• w = v+g
• x = h+i
• y = j+k

As a classic computer design, a scalar processor such as the Intel 486 and the Arm 1176 will execute one instruction for each cycle of the system clock. These six instructions will take six clock cycles.

To increase the performance in such a system was simply a matter of increasing the clock speed. However, this runs into two problems. The first is that there is essentially a limit to how fast logic gates will run and secondly, memory read and write speeds have increasingly lagged behind processor speeds. An alternative to increased clock speed is to get the processor to try and do more than one instruction at a time – creating a superscalar processor. If we have a two-pipe processor then it would execute pairs of instructions at the same time. The same pseudo code would be thus:

• t, u = a+b, c+d
• v, w = e+f, v+g
• x, y = h+i, j+k

And, in theory, half the execution time

Examining the code reveals a problem. The second pair of instructions can’t be executed simultaneously as v has to be completed before w can executed. Pipe 2 has to wait until Pipe 1 has completed, like this:

• t, u = a+b, c+d
• v = e+f            # second pipe does nothing here
• w, x = v+g, h+i
• y = j+k

The result is four clock cycles rather than three – still an improvement.

But as the only dependency is between w and v, we could re-order the instructions by swapping w and x and this would give us:

• t, u = a+b, c+d
• v, x = e+f, h+i
• w, y = v+g, j+k

This is the optimal three instructions that we get with two pipes. Examples of out of order superscalar processors are most Intel and AMD x86 processors from Pentium 2 onwards, and most recent Arm cores.

In real life programs are more complex than our little set. The biggest difference is they incorporate branches. These may be unconditional (always taken) or conditional (depending on a computed value). They may be forward (if statements) or backward (loops). They may be direct – to a specific target address - or indirect using an address from a register, a memory location or from the processor stack.

So that execution doesn’t stall when a branch is encountered, processors use branch predictors which use statistics from previous branches to make an informed guess about whether the branch will be taken. Another technique used when there are triple or quadruple pipelines is speculation. This is attempts to guess what instructions will be needed and then carry them out. If they are not used, perhaps a branch has made them redundant; then the result is discarded. With the help of the branch predictor to advise on likely paths, an instruction speculation can provide significant speed up in programme execution.

But we said earlier, memory is not keeping up with the execution speed. To get around this processor designers use caches, that is small stores for subsets of the memory on the processor chip. This will hold copies of locations in the main memory that have recently been accessed or that are close to a location already accessed, as these are the most likely to be required soon.

With these tools there are two possible things an attacker can use. The first is that the branch predictor can be trained to make poor predictions. And if they measure the time of a memory access they can see if the address was in the cache or not.

With this information the Meltdown attacker is able to read information stored in the operating system kernel while with Spectre, the attacker can read the memory area of other running programs which should be inaccessible.

Figure 1. The core instruction sequence of Meltdown

To get into the target hardware, the attackers could use a short JavaScript programme. In the case of systems running a web browser (such as a cell phone or a tablet) this can be from running an infected web page. Other devices, such as IoT end points, can be attacked by the malware trawling the web looking for weakly protected device, the same approach used by Mirai. Once a Meltdown or Spectre attack has taken place, there is no forensic evidence in the compromised system.

Despite the enormous coverage and publicity, there have been no recorded cases of either Meltdown or Spectre.

Who Is Affected?

Meltdown is mainly a problem on Intel processors. Any Intel processor since 1995 is vulnerable, with the exception of Itanium and some Atom CPUs. Arm has also reported that the Cortex A-75 core is vulnerable. Outside the embedded world, Apple has said that most of their products are vulnerable and has issued updated operating systems across the range.

Spectre is more widespread, with many Intel and AMD processors vulnerable. Arm Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73 and Cortex-A75 cores are all vulnerable. While these cores are at the heart of many processors, the most popular core family for embedded and IoT use is the Cortex M, which is not vulnerable and Arm points out that the Cortex-R cores are mostly used in closed systems, where there is often no interface for an attacker to use.

Raspberry Pi uses none of the vulnerable cores (Raspberry Pi 3 and later Raspberry Pi 2 use the Broadcom BCM2837, which has the Arm Cortex-A53) so it is immune to both Spectre and Meltdown.

With the wide range of board products that are available, the picture is less clear. Since board selection is about matching performance and features to the needs of the application, these will continue to be the overriding criteria. But developers might prefer to choose a board that is less susceptible to these threats, rather than try to use some of the measures that are available to mitigate their effects.

Mitigation

Since the original reports there has been a landslide of possible mitigation measures, from chip manufacturers and Arm, as well as the developers of operating systems. The major operating system vendors have issued updates that go some way towards mitigating, if not completely stopping, these attacks. The anti-malware people have also made updates to their products that might help in stopping the actions that trigger the attacks.

The hardware people have also issued various possible mitigating fixes to their microcode, but the problem is that Meltdown and Spectre are exploiting the design decisions that are intended to speed up the system performance and the mitigating measures have the effect of slowing down the processor. Initial press comment has suggested that this performance hit can be significant, as much as 25%. This has been revised downward, but the situation is muddied by Intel having to pull their microcode updates and rolling out a series of processor family specific updates, for which, at the time of writing, there are no performance estimates. The other problem is that many of the commentators and tester working on this topic are PC people, and IT people, and are not measuring the impact for embedded systems.

There are some fixes from Arm that are linked to the operating system. Again, it is not clear what the performance penalty is for applying these fixes.

Embedded products often work in real time, and, again at the time of writing the RTOS vendors have not commented, except for one which claims that its RTOS is immune to the problem. Embedded developers often chose a processor by balancing power/performance and specify a processor working to close to the limit of the timing needed. Even a small fall in performance can potentially cause the application to fail.

What Should IoT Engineers Do?

With the IoT there are, simplistically, several points to consider. The edge devices, where information is collected and devices are controlled; the gateway, which collects feeds from multiple devices and feeds it into the network; the network processors and finally, the servers in the cloud. For the servers, companies such as Amazon are working hard at further improving the isolation between different users and increasing other security measures. On the whole, ethernet network processors are not impacted by Meltdown and Spectre. The gateway systems are potentially at risk and much of what is said about the edge devices applies to gateways as well.

Looking at the IoT edge there are two issues. Firstly, products that already deployed and secondly, future products.

Many deployed IoT products are using lower end processors, Cortex M cores. With these there is no risk of either attack. Whatever the processor it would be sensible to carry an audit of all deployed products and assess their vulnerability, including the risks from an attack and consider whether you need to issue any patches. There should also be in place a company strategy for dealing with future security issues, as these are almost certain to occur in processors, communications chip or the IoT product itself.

For new products, security has to be included in the design requirements. (The Barr Group’s 2018 survey shows that the requirements for less than 22% of IoT projects in 2017 included security.) And since, even with great care in design and implementation, there are always going to be future issues, the design requirements should also include making provision for potential work-arounds and field-fixes.

Since field-fixes for software are expensive, and issuing replacement boards is even more expensive, it is much cheaper to invest more time and effort into building robust and secure systems. Even small things like making the first use of the system only possible if the user re-sets access passwords from the factory default will limit vulnerability. (And it only requires a few lines of code to stop the use of the common fall backs – such as password, 123456, or asdgfg). Look carefully at what access you need to which parts of the system. Maybe you can have multiple levels of security for different tasks.

For the time being, until the vulnerable processors are released with firmware that stops Meltdown or Spectre, examine alternative routes. Use good programming practice and tools to develop code that will be of high quality. And finally, expect that there will be another problem along shortly.

Meltdown and Spectre: The Impact of Processor Bugs on IoT Security. Date published: 15th March 2018 by Farnell element14