Processor Vulnerabilities Put Virtual Workloads at Risk

Back in January 2018, a consortium of security researchers from organizations including Google, Cyberus Technology and several universities disclosed two ominously-named vulnerabilities found in nearly all modern computer processors. These vulnerabilities broke open the floodgates for research into flaws in some of the most fundamental security protections found in computer processors. Meltdown, Spectre, and the other related vulnerabilities are significantly more dangerous and useful to an attacker in a virtual environment versus a non-virtual server or desktop. In response, I expect to see Intel and AMD eventually create separate processor lines to protect cloud applications from this threat.  

The Processor Speed Race
Modern processors handle dozens if not hundreds of applications simultaneously. Billions of transistors packed into multiple cores allow them to seamlessly and automatically switch between execution threads as needed. They typically enforce a set of rules on this dance of applications, including one very big one: The processor should prevent applications from accessing data from other running applications. Meltdown and Spectre allow malicious applications to break this rule.

Processing power continues to increase each year, but no longer at the same rates that we used to see when Moore's Law still held true. Processor manufacturers have to use clever "cheats" to squeeze more performance from their devices as they run into limits of transistor technology. One of these cheats is an optimization technique called speculative execution 

Speculative Execution: Faster but Flawed
In a nutshell, application execution paths often contain many forks, or branches, where they may go down one of multiple code paths depending on the result of a calculation. The processor doesn’t know what branch the application will follow until it completes the calculation, but it can save time by guessing the outcome and continuing execution down that path while it waits for the calculation result. If it guessed correctly, it already has a head start and saves a few microseconds. If it guessed incorrectly, it simply discards the work it started and continues down the correct path.

Meltdown and Spectre both abuse speculative execution, though in slightly different ways. While the technical explanation could take a full article in itself, the short story is that they use speculative execution to load restricted memory into the processor’s memory cache and then use a few tricks to accurately identify the contents of that memory even after the process recognizes they shouldn’t be able to read it directly. The restricted memory could include anything from an administrative password to sensitive cryptographic keys on a Web server.

Spectre and Meltdown in the Cloud
While expanding the potential impact of malware on a desktop or non-virtualized server is never good, Meltdown and Spectre become much more dangerous in the cloud and virtual environments. An attacker with code execution on a physical desktop or server usually has much easier ways to elevate their privileges and access sensitive data from other applications. Using Meltdown or Spectre would be excessive.

But in a virtual environment, a single piece of hardware (for example, an EC2 instance in an AWS data center) can house multiple different tenants, each of which expects their applications and services to be completely isolated from the other tenants with which they share the resources. Usually, the hypervisor (the management software that handles virtualizing a single piece of hardware into multiple virtual servers) has strict security controls to enforce tenant isolation. 

But Spectre and Meltdown completely bypass these software protections by targeting the hardware itself. An attacker with access to one application on a cloud server could steal data from all the other applications using a shared resource on the same physical hardware, no matter how good the security of those other applications is!

Since Meltdown and Spectre's disclosure, researchers have found several variants and other vulnerabilities that abuse speculative execution to access restricted memory. Intel and AMD, the two largest processor manufacturers, have been playing a cat-and-mouse game of patching these flaws, usually at the cost of processor performance. The performance loss has been up to 30% in extreme cases. This has led many desktop users, who are less impacted by Spectre, Meltdown, and the like, to disable the security options to retain more processing power. 

How to Solve the Problem
Mitigating this type of vulnerability in a cloud environment where security is paramount ranges from difficult to impossible. Patching these vulnerabilities requires difficult microcode updates to the processor itself. Because of these challenges, we’re likely heading towards a future where Intel and AMD manufacture different classes of processors that focus on either security or speed.

Cyber security is all about risk trade-offs. Desktop computers and non-virtualized servers have less to lose from an attacker successfully exploiting a Meltdown-like vulnerability than virtual environments, where an exploit could be a disaster. Since their risk is substantially lower, they could benefit from remaining vulnerable in return for significantly better processor performance. Processors used in virtual environments would likely swing the other way: prioritize security over speed by removing speculative execution entirely (or possibly something slightly less drastic). This could lead to different processor lines, one focused on security with slightly degraded performance and another focused on pure execution speed that risks falling victim to speculative execution attacks.

Researchers have already opened Pandora’s box for processor security vulnerabilities and the days are clearly numbered for speculative execution in its current form. Since the original Meltdown and Spectre disclosures, researchers have discovered additional serious flaws nearly every other month. At this rate, something will have to change to keep cloud applications safe. Whether that will be a fundamental re-architecture on all processors or a split into different security and performance-focused lines remains to be seen.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "In App Development, Does No-Code Mean No Security?"