Hardware vulnerabilities

What are hardware vulnerabilities? Is it absolutely necessary to attempt to correct them? If so, are there affordable solutions?

Gabriel Augendre

Nov 30, 2018 • 7 min read

💡

This is a translation of an article originally published on Medium in French.

This article was written in collaboration with Emmanuel Gublin and is aimed at a curious, non-specialist audience with some basic knowledge of modern architectures.

Recommended prior reading: Modern Microprocessors - A 90-Minute Guide!

Strong assumptions

Many modern systems today are based on clever software engineering. Developers rely on strong hardware assumptions to build these systems, such as the hardware isolation of processes and threads (two processes have no influence on each other), the electrical isolation of RAM cells from each other (one cell has no electrical influence on another), the MMU forbids access to an unauthorized memory area, and so on.

These assumptions were mostly true a few decades ago, but today, after an ever fiercer race for performance between processor manufacturers, some of them have been invalidated: two threads can run on the same processor core and therefore share hardware resources, DDR3 RAM cells are ultimately not isolated enough, and speculative execution allows the CPU to access memory areas or hardware resources before authorization has been verified.

The origin of hardware vulnerabilities

The vulnerabilities listed in the appendix below are present either on a purely hardware level (Row hammer), or in an embedded system alongside the processor (Intel Management Engine), or in the processor instruction set (Portsmash, Spectre and Meltdown).

They are often born out of the quest for performance or convenience: more memory, remote management, ever-higher overall performance... For example, the speculative execution used by Spectre and Meltdown enables instructions to be executed ahead of time, if the prediction comes true.

They are particularly vicious in that they are completely invisible to conventional detection tools, which are limited to the operating system and cannot intervene at such a deep level in the machine.

Serious but difficult to act on

The impacts of these vulnerabilities are diverse and serious: to break out of a sandbox, gain root access or extract information from a more privileged context. For example, on some systems, the user's privileges are stored in RAM at an address belonging to the kernel, so only he can legitimately modify this value. Row hammer allows you to modify the bits of any memory cell, provided you know which zone you want to target, so you can modify a user's privileges without permission.

However, these impacts need to be put into perspective, as most hardware vulnerabilities are very difficult to exploit. They often require direct access (not necessarily physical) to the machine, as in the case of Spectre, Meltdown or Portsmash, or even extremely precise knowledge of the state of the machine in question for Row hammer, which requires targeting a specific memory address to obtain interesting results.

Corrections almost impossible on a large scale, but not necessarily required for everyone

It is not easy to correct these vulnerabilities, most of which are due to hardware design problems. To protect against their impact, in some cases it would be necessary not to apply a software patch, but to replace the hardware, which is much more costly. In other, rarer cases, a software patch can resolve or at least mitigate the effects, but at the cost of performance. As a result, many companies consider that their threat model does not cover these vulnerabilities, and choose to live with them.

However, not everyone can afford this. IaaS service providers such as OVHcloud, Amazon, Google, Microsoft and others cannot ignore threats that allow information to be extracted from a privileged context to a less privileged one (e.g. from the hypervisor to the guest system).

Portsmash, Spectre, Meltdown and Row hammer are direct threats to these companies. Indeed, these vulnerabilities could enable an attacker with legitimate access to a virtual machine to access information from neighboring VMs, or even to escape the hypervisor-imposed sandbox. These are therefore serious risks for these companies and their customers, who could see sensitive data escape.

On the other hand, the average user may not have much to worry about. These attacks are complex enough to set up, and require very precise knowledge of the target system. It therefore seems unlikely that they will be deployed on a large scale for the time being.

Take away

As we've discovered throughout this article, hardware vulnerabilities are diverse in nature, and security researchers are discovering new ones on a regular basis. Protecting yourself from their effects can be as simple as deploying a patch, but it can also be as complex and costly as changing the hardware component concerned. Not all players are threatened to the same degree: the average user will have little to worry about, while service providers such as IaaS will have more to worry about.

Appendix: Identity cards for some hardware vulnerabilities

PortSmash

Type: CPU

Allows: Data extraction from another thread

Impact:

Intel Skylake and Kaby Lake architectures were impacted in the researchers' proof-of-concept, but they assume it goes beyond that and impacts all processors that use Hyper Threading, including AMD.
This would be particularly interesting to exploit in an IaaS-type infrastructure, since resources are often shared.

How does the attack work?

By measuring the waiting time imposed on the spy thread to access a hardware resource. We assume that this waiting time is dictated by the processor scheduler so that the victim thread can also execute. A lot can be learned. The researchers were able to extract an SSL private key in their proof of concept, but it could be something else entirely.

Possible fix? Known? Intel's hyper-threading must be disabled, at the cost of heavy performance losses.

Notions: Shared resource, Bottleneck, Timing

Further information:

Spectre / Meltdown

Type: CPU

Allows:

Meltdown: read kernel memory in a user program
Spectre: leak information from kernel space to user space, but also from a hypervisor to a guest system
Spectre could allow escape from virtualization imposed by a hypervisor

Impact: Intel chips are affected by Spectre and Meltdown. Proofs of concept have been completed for Spectre on AMD and ARM chips, but not for Meltdown. That said, researchers suspect that it could still be possible.

How does the attack work?

Meltdown: when certain calls are made to the kernel, the check as to whether they are allowed to be made is carried out after the speculative execution has begun. Precise timing can determine whether certain memory addresses are loaded into the kernel cache or not.
Spectre : based on a larger class of speculative executions, such as branches (if, while, for), then ditto with precise timing to determine whether certain addresses are loaded.

Possible fix? Known?

Meltdown: Fixed. OSes will first check that the call is authorized before executing it. This has a significant cost for programs making many system calls (network, disk).
Spectre : No obvious solution. Speculative execution is necessary to achieve a certain level of performance. Manufacturers will or have added specific instructions to wait until all memory operations have been completed before executing new ones, but it's not easy to know where to place them (hard/impossible to automate).

Notions: speculative execution, timing

Further information:

Vulnerabilities in the Intel Management Engine (IME)

Type:

Software inside CPU
The Intel Management Engine is a system embedded in most Intel processors. The code is largely obfuscated and operation is undocumented. A security researcher claims that this embedded system, which runs on a chip separate from the main processor, has direct access to memory and the TCP/IP stack, and can therefore communicate over the network independently of the machine's OS.
Numerous vulnerabilities have been detected in this embedded system.
This system is beyond the reach of the usual security tools, which run as services on the OS and have no access to this parallel system, which therefore operates independently.

Allows: Remote execution of arbitrary code with root access.

Impact: Intel processors from generations 1 to 8 are affected, as well as several Xeon processor ranges (servers) and certain Atom, Pentium and Celeron processor families. We're talking about most desktops, laptops and servers in circulation.

How does the attack work? We're talking here about a family of vulnerabilities in this embedded system, and therefore different attack scenarios. Most require physical access to the machine, but some allow remote execution.

Possible fix? Known? Patches have been released by Intel and PC manufacturers.

Notions: Embedded system, System beyond the reach of safety tools

Further information:

Row hammer

Type: RAM

Allows:

Escape from a sandbox to execute system commands
Unlimited access to all system memory
PoC root access on Android

Impact: All machines with DDR3 and many with DDR4

How does the attack work?

By rapidly activating two physical memory lines separated by a "victim" line, we can cause a change of electrical state on transistors on the victim line, and thus change bits on that memory line.
This is because DDR3 is very dense and the isolation between memory lines is not very effective.
You need to know exactly where to "strike" in order to use this exploit. Doing it at random on a given line won't necessarily yield an interesting result.

Possible fix? Known? It is possible to mitigate the effect by refreshing potentially affected memory areas more often. However, these mitigations are hardware-based rather than software-based. It seems difficult to reduce the effects on a machine that does not have hardware specifically designed to mitigate this exploit.

Notions: Electronic design of random access memory, Electrical disturbances

Further information:

Strong assumptions

The origin of hardware vulnerabilities

Serious but difficult to act on

Corrections almost impossible on a large scale, but not necessarily required for everyone

Take away

Appendix: Identity cards for some hardware vulnerabilities

PortSmash

Spectre / Meltdown

Vulnerabilities in the Intel Management Engine (IME)

Row hammer

Sign up for more like this.