Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

1/14/2020
10:00 AM
Marc Laliberte
Marc Laliberte
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Processor Vulnerabilities Put Virtual Workloads at Risk

Meltdown, Spectre exploits will likely lead to customers making tradeoffs between performance and security of applications, especially virtual and cloud-based apps

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?"

Marc Laliberte is a senior security analyst at WatchGuard Technologies. Specializing in networking security protocols and Internet of Things technologies, Marc's day-to-day responsibilities include researching and reporting on the latest information security threats and ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
jonathanlevitt
50%
50%
jonathanlevitt,
User Rank: Apprentice
7/4/2020 | 10:19:14 AM
Processor
The discovery of the Spectre and Meltdown threats came as a shock to most individuals and organizations. The underlying vulnerabilities that they exposed continue to affect PCs, smartphones, servers, network and security appliances, and some IoT devices. Thank you for sharing on how to prevent and solve these kinds of attacks, I hope that the processor manufacturers will create processor lines to protect cloud applications from this threat. Jonathan from https://redbytesite.com

 
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Another COVID-19 Side Effect: Rising Nation-State Cyber Activity
Stephen Ward, VP, ThreatConnect,  7/1/2020
Lessons from COVID-19 Cyberattacks: Where Do We Go Next?
Derek Manky, Chief of Security Insights and Global Threat Alliances, FortiGuard Labs,  7/2/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15600
PUBLISHED: 2020-07-07
An issue was discovered in CMSUno before 1.6.1. uno.php allows CSRF to change the admin password.
CVE-2020-15599
PUBLISHED: 2020-07-07
Victor CMS through 2019-02-28 allows XSS via the register.php user_firstname or user_lastname field.
CVE-2020-8916
PUBLISHED: 2020-07-07
A memory leak in Openthread's wpantund versions up to commit 0e5d1601febb869f583e944785e5685c6c747be7, when used in an environment where wpanctl is directly interfacing with the control driver (eg: debug environments) can allow an attacker to crash the service (DoS). We recommend updating, or to res...
CVE-2020-12821
PUBLISHED: 2020-07-07
Gossipsub 1.0 does not properly resist invalid message spam, such as an eclipse attack or a sybil attack.
CVE-2020-15008
PUBLISHED: 2020-07-07
A SQLi exists in the probe code of all Connectwise Automate versions before 2020.7 or 2019.12. A SQL Injection in the probe implementation to save data to a custom table exists due to inadequate server side validation. As the code creates dynamic SQL for the insert statement and utilizes the user su...