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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-7263
PUBLISHED: 2020-04-01
Improper access control vulnerability in ESConfigTool.exe in ENS for Windows all current versions allows a local administrator to alter the ENS configuration up to and including disabling all protection offered by ENS via insecurely implemented encryption of configuration for export and import.
CVE-2020-7066
PUBLISHED: 2020-04-01
In PHP versions 7.2.x below 7.2.9, 7.3.x below 7.3.16 and 7.4.x below 7.4.34, while using get_headers() with user-supplied URL, if the URL contains zero (\0) character, the URL will be silently truncated at it. This may cause some software to make incorrect assumptions about the target of the get_he...
CVE-2020-11445
PUBLISHED: 2020-04-01
TP-Link cloud cameras through 2020-02-09 allow remote attackers to bypass authentication and obtain sensitive information via vectors involving a Wi-Fi session with GPS enabled, aka CNVD-2020-04855.
CVE-2020-7064
PUBLISHED: 2020-04-01
In PHP versions 7.2.x below 7.2.9, 7.3.x below 7.3.16 and 7.4.x below 7.4.34, while parsing EXIF data with exif_read_data() function, it is possible for malicious data to cause PHP to read one byte of uninitialized memory. This could potentially lead to information disclosure or crash.
CVE-2020-7065
PUBLISHED: 2020-04-01
In PHP versions 7.3.x below 7.3.16 and 7.4.x below 7.4.34, while using mb_strtolower() function with UTF-32LE encoding, certain invalid strings could cause PHP to overwrite stack-allocated buffer. This could lead to memory corruption, crashes and potentially code execution.