Skip to content ↓ | Skip to navigation ↓

If this first week is any indication, 2018 could mark a significant paradigm shift in trusted computing and open source hardware. Chip makers have been very effective in making enhancements to greatly improve application performance, but the revelation of Spectre and Meltdown makes it clear that more attention needs to be paid to hardware level security. These attacks are able to abuse certain performance features to leak information in violation of fundamental security constraints.

What is Meltdown?

Meltdown, which at this time is only known to impact Intel-based CPUs, exploits out-of-order execution to gain unrestricted read access to system memory. This has particularly devastating impacts for systems relying on isolation techniques like containerization or paravirtualization for security since an attacker can break through the isolation to read from co-located instances.

What is Spectre?

Spectre, which is known to impact virtually all modern processors, is a class of microarchitectural attacks that abuse the way processors perform branch prediction through speculative computation to read confidential information from a process. Perhaps the most shocking revelation of Spectre is that the researchers were able to create a side channel to leak memory from a Chrome browser process via JavaScript.

It is also worth noting that these attacks were found independently by two separate research efforts.

In addition to the team of esteemed researchers behind Spectre and Meltdown, Google’s Project Zero was also working with Intel, AMD, and ARM as outlined in their blog post: Reading privileged memory with a side-channel. It is unknown at this time whether any other groups had private knowledge of these flaws prior to this disclosure.

Due to the low-level nature of these bugs, fixing the bugs is non-trivial. Meltdown requires considerable changes to the way the OS provides memory isolation. Fortunately, an effective design was previously published by a team including some of the same people who found Meltdown. This design, named KAISER, was created to protect against attackers using hardware to bypass kernel address randomization (KASLR) but incidentally protects against Meltdown as well. All relevant OS vendors are now implementing their versions of KAISER. The Linux implementation of this, named Kernel Page Table Isolation or KPTI (despite some other interesting choices), inadvertently started a firestorm of rumors which forced an earlier than planned disclosure of Meltdown and Spectre when The Register got wind of the change. Patches are available for various systems including Windows as noted in the VERT alert.

Unfortunately, KAISER is not an effective countermeasure against Spectre and, in fact, there is no clear solution to this class of bugs.

For some scenarios, it is possible to restrict speculative computation through software changes but such changes are highly environment specific and can lead to extreme performance degradation. There are also some ways that microcode updates can defend against Spectre attacks but it seems likely that these will only be Band-Aid style fixes pending more comprehensive research. There are however application specific mitigations to consider including browser mitigations for Mozilla, Chrome, and Edge.

This situation highlights the bizarre state of computer security in 2018.

In recent years, security research has made huge advances in software based protections but we are gradually learning that many of these protections can be undermined at the hardware level. Moreover, the degree of secrecy surrounding many hardware designs greatly hinders research efforts into the most fundamental levels of security protection.

My hope is that increased awareness of critical flaws in opaque systems like CPUs, GPUs, secure enclaves, WiFi chipsets, EFIs, TPMs, and similar devices will encourage more transparency between the vendors making these systems and the public security research community.

Read VERT’s latest Threat Alert on Spectre and Meltdown here.

To learn more about Tripwire, click here.

['om_loaded']
['om_loaded']
<!-- -->