CPU Architectural Design Flaws

Thursday, January 4th, 2018

Overview

Google announced three major vulnerabilities that can be exploited in today’s central processing units (CPUs). Major processor vendors, operating system vendors, and application vendors were pre-notified. Therefore, they would be able to address this critical issue. Most modern CPU’s are affected.

Description

This collection is based on a number of articles, including those from Google and independent researchers formally releasing the information, surrounding the flurry of activity over issues with most modern processors.

The vulnerabilities involve an architectural feature built into CPUs to enhance system performance. Remediation efforts could adversely impact performance, affecting software, apps and browsers. The vulnerabilities are known to be exploitable on servers, workstations, mobile devices, IoT environments and browsers.

In a much simpler time, microprocessors were designed to have their memory separated out into what is called “kernel space” and “user space”. In a 32-bit Intel environment, which is limited to four gigabytes of addressable space, the kernel space was regulated to the top one gigabyte of memory while the user space resided in the lower three gigabytes. While it might appear that applications running in the user space had visibility into the kernel space, permissions (theoretically) prevented direct access into the kernel’s memory.

KASLR

The four gigabyte size restrictions for virtual memory were removed with the 64-bit Intel environment. Unlike the 32-bit architecture that always loaded the kernel in a known location in upper memory every time the system was booted, a kernel loading process called kernel address-space layout randomization (KASLR) was implemented. Each time the system boots, the kernel space is assigned a random location in the virtual address space. This makes attacking vulnerabilities in the kernel a little more difficult since the attacker does not know the specific location in memory to attack. However, applications running in the user space still have the same theoretical visibility, barring permissions, into the kernel space as the 32-bit architecture.

TLB

The processor has a “Translation Lookaside Buffer” (TLB) that is used for switching between user space and kernel space. By keeping the kernel space permanently mapped in the TLB, the kernel space TLB entries do not have to be flushed, which is a time-consuming operation. Without this design, for each context switch (which occurs at least twice for each system call), the TLB would be flushed and repopulated with the appropriate TLB entries (user space or kernel). Examples of the need for a context switch include system calls (i.e., disk read, write, or seek), system interrupts, or time slicing requirements.

So long as memory leaks from kernel space do not find their way into user space, an attacker would not be able to infer the kernel’s location. Unfortunately, such leaks do occur, either from software errors or the hardware itself.

The researchers discovered that user space instructions can be used to retrieve kernel memory due to processors’ use of “speculative execution” that will attempt to guess what code will be executed in the next few cycles and “pre-execute” it in an attempt to increase performance. At times, this may mean that multiple code segments are pre-executed at the same time until the correct one is needed. The other segments are then discarded.

Researchers have identified three vulnerability variants:

CVE-2017-5715 is an elevation of privilege / information disclosure vulnerability. Taking advantage of a new method of side-channel analysis while running on a local system, an attacker potentially might be able to infer data values from memory not normally accessible by a user because of permissions. Based on a previous vulnerability, “branch prediction”, this vulnerability goes one step further and attempts to inject or affect potential branches in kernel space from user space code. This could provide memory details that would not otherwise be possible.

CVE-2017-5753 relies on the fact that the processor may load out-of-bounds code during the speculation phase of processing. To exploit, an attacker would need to trick the CPU into loading from an untrusted location. Unlike the code the CPU would normally load, the attacker’s code is longer. This results in an out-of-bounds condition for that read, overwriting a portion of the L1 cache. This would result in execution returning to a non-speculative path. The attacker can measure the cycles required to load the data for the different paths and determine which path the CPU chose.

CVE-2017-5754 exploitation allows an application in user space to read kernel space memory without any influence or misdirection of code running in the kernel space. This exploitation relies on the fact that the CPU may opt to validate permissions to access memory locations until a later point in time. This opens a timing window that the attacker can exploit. They can expand by promptly executing an instruction behind a high-latency mis-predicted branch. This could allow an attacker in user space to access memory in kernel space without the usual permission checks.

Remediation

Remediation will likely come from two sources – firmware updates from hardware vendors and software updates from application vendors. Software updates will be in the form of operating system patches as well as potentially from applications themselves.

These patches may have a performance degradation due to the nature of the fixes. The degradation will vary depending on the workload and environment of each system. For example, a system in a text-based environment, running minimal software, performing purely memory based calculations might not show a large performance hit. On the other hand, a system with a GUI, primarily used as an information repository with a lot of disk and network activity, may see a larger drop in performance. We suggest applying the patches in a test environment to get a better idea of what level of performance you can expect when the patches are applied to your production environment.

Vulnerabilities

What Is Affected

Servers
Workstations
Laptops
Cell phones
Tablets
Smart TVs
IoT devices
Other devices with affected CPUs

Compromise Impact

Remedies

Credit

Google Project Zero
University of Maryland

References

[avatar user=”rmurphy@smarttech.ie” /]

Smarttech247

Contact Us

The data you supply here will not be added to any mailing list or given to any third party providers without further consent. View our Privacy Policy for more information.