AUTHOR UPDATE: As per usual with technology stories, by the time we hit “Publish” on this post there was already another development brewing with the recent announcement of the ‘BranchScope’ exploit which is similar in method to Spectre/Variant2, but uses Intel’s Software Guard Extensions (SGX). Finding attacks leveraging SGX is concerning because SGX is used to “carve out small sections of encrypted code and data such that” even the OS or hypervisor shouldn’t be able to read it.
Ars’ summary is on point in that the full scope of impact (large or small) of both Spectre and the new BranchScope method is still unclear, but the actual point made is that the boundaries and guards between applications and other apps, and applications and hardware, are not as strong as once was thought. For many in the security world who find and work with data leaking exploits every day, this is business as usual. For most consumers and users, both business and personal, this is another layer to tease through in an already very deep problem, with changes happening rapidly and only their data and privacy at risk. Watch this space.
—
In mid-November, I wrote about the Intel vulnerabilities that were discovered with the IME and AMT technologies. I covered the details on the remote management access vulnerabilities on desktops and laptops (usually corporate fleets) that Intel had super-secured with things like a blank admin password.
Intel vulnerabilities hit the mainstream again with the widespread release of details on the Spectre and Meltdown attacks around January of 2018. The following weeks were a veritable trainwreck as Intel, Microsoft, Apple, antivirus software makers, and hardware OEMs scrambled to achieve the following, in no particular order:
Many of which happened simultaneously, leaving risk and technology managers with their heads spinning, wondering what their actual exposure is, and unsure of how to explain the current situation to executives, managers, and clients.
So, in this post, we’re going to dive into the actual risk, where we are today, and some of the timeline and the chain of events of this global (not an understatement) security risk. We’ll include some translations along the way for the risk managers of the world. Let’s start at the top.
Spectre and Meltdown are “bugs” (flaws) in the design of CPUs that have been present for years (1995 by some estimates) but were only recently exposed (~June 2017).
Spectre gets its name from “Speculative Execution” which is a function in CPUs which tries to guess what you’re likely to do next, then starts working on it so that when/if you actually do that thing, it happens quicker. If you’re at a fork in the road wondering whether to go left or right, Speculative Execution says “I’ll start working on going both left AND right” so that no matter which direction you go, you’re not sitting waiting for your task to load any longer than necessary. Intel brought Speculative Execution to consumers with the Pentium II processors around 1997, and it’s been a key performance booster in processor design from Intel, AMD, and ARM ever since.
(Both Spectre and Meltdown use Speculative Execution, but they each leverage it in conjunction with other processor features. More on that in a bit.)[
The answer is simple: Intel implemented Speculative Execution without the necessary security checks everywhere it should have. The exploits (both Meltdown and Spectre) take advantage of Speculative Execution.
To Intel’s credit, it’s taken 20 years of usage and design iterations before these exploits were discovered. This is a nuanced exploit rooted deeply in processor designs, and far from a simple security oversight.
Let’s sum this up: Researchers discovered how to use a performance-boosting feature in Intel processors (Speculative Execution) to read protected memory that a user or application would normally not be permitted to access.
That’s the “high level” explanation, but there’s more to the story: Meltdown and Spectre each use another processor feature to achieve their ends.
Spectre uses Branch Prediction along with Speculative Execution. Branch Prediction and Speculative Execution each do similar things (predict the next task so it loads and runs faster) but Branch Prediction goes the next step and predicts the results of the task. The processor tries to think ahead of what the task wants to do, including by finding and pre-loading memory addresses, and will proactively start loading instructions based on what it predicts will happen. Using Spectre, the exploit has the processor fetch memory addresses, which then get moved into the processor cache where the attacker can read it.
Meltdown, on the other hand, operates slightly differently. Processors and memory have two modes: Kernel mode and User mode. Kernel mode is for system stuff (like your OS) and User mode is where non-system apps work from (browsers, email, document editors). The way it’s supposed to work is programs which run in User mode can only see their own memory, and programs in Kernel mode can read everything (since the kernel is running the show) but access to it (Kernel mode) is limited. Meltdown “melts down” those restrictions – separating User mode programs from Kernel mode memory spaces – by sending instructions to the processor out of order, then Speculative Execution follows those instructions and reads kernel space memory before security controls have a chance to say “You don’t have permission” which would normally occur by generating an exception and terminating the process’ thread.
You may have seen references to “Variants 1 and 2” and “Variant 3”. This is because the “speculative execution” flaws have 3 known ways of being used: 2 methods (Variants 1 and 2) are Spectre, and the third (Variant 3) is Meltdown. Here’s a quick list of major points about each:
| Spectre (CVE-2017-5715, 5753) (Variants 1 & 2) |
Meltdown (CVE-2017-5754) (Variant 3) |
| Affects Intel/AMD x86/64bit + some ARM (back to 1995) | Affects Intel, AMD, & certain ARM Cortex |
| Affects PCs, Macs, iOS, and IoT devices | Affects “almost every” x86 PC and Mac since 2010 |
| Can access same-OS protected memory at the same privilege level | Can access protected memory across VMs |
| Can dump other app’s memory in seconds/minutes (~120kb/sec) | ~5-10kb/sec, reaching across VMs would take days + spike target performance (high CPU) |
| Can only run in the same ‘privilege’ level | Needs root/admin |
| Can be fixed by changes in kernel | Short term: Some self-governing software fixes
Long term: Changes in silicon architecture |
TechCrunch provides an excellent synopsis of these variants:
“Variant 1 is arguably the most difficult of them all to fix, and as such Intel doesn’t have a hardware solution for it yet – but variants 2 and 3 it has in the bag.”
“In the bag” means Intel has put in the fixes for variants 2 and 3 in the upcoming versions and models of Intel processors (Cascade Lake Xeon and 8th-generation Core processor lines.) That’s great if you’re about to buy a new computer, but not so helpful if you’re wondering what to do with the few dozen, hundred, thousand, or dozens of thousands you already have – though Intel promises microcode updates going as far back as the first-generation “Core” processors.
That’s a lot of processors, and a lot of computers and servers. And when it comes to the fixes, there is both good news and bad news.
The bad news: the flaw is baked into the processor design. It can’t be “fixed” in the sense of removing the problem. It can only be fixed by workarounds and changes in software (like Windows) and firmware (like your computer’s BIOS.) In essence, these fixes route you to slower streets around the pothole because they are not able to fix the main road – yet.
Now here’s the good news:
With this vulnerability, there are two main types of compromise:
Broadly, those are significant vulnerabilities. On a single host, like a laptop or desktop, malicious code in a web page or “malvertisement” could use the Meltdown exploit (CVE-2017-5754) and read the memory of a program running outside and beyond the browser, and then quickly, read the contents of memory in minutes. It could read – and then post to the attacker – sensitive info like the contents of a document, spreadsheet, encryption keys or passwords from a VPN application, or a password manager.
That risk of data leakage is amplified on a virtual host because two of the three known methods, the Spectre variants (CVE-2017-5715, 5753) could allow VMs to read protected memory of other VMs. While most of the major cloud providers claim to have patched for Spectre, only time, along with rigorous third party testing, will tell us if their fixes are up to the task. Some of the small providers are entirely reliant on chip manufacturers to provide performant fixes.
That means a compromised VM – such as an Apache webserver owned by a customer running behind on their updates – could read the memory of any other VM running on the same hardware – such as a directory or database server run by a different customer, even if Customer2 is up to date with their patches.
Now that latter example sounds scary, and it should. However, there is a drawback for cyber criminals looking to exploit the Spectre vulnerability which has gone largely unreported. Dumping memory contents across VMs is a painfully slow process – around 10kbytes per second – and also generates a prolonged spike in CPU usage. So while a bad actor could conceivably grab memory data across a VM host, they’d have to either know exactly where in memory to find what they wanted or dump the entire memory stack, which – for a VM with 4 gigabytes of memory, copying at 10kb/sec – would take just shy of 40 days to complete. And during those 39 days and change, the VM’s CPU is running really hard and fast, and the memory contents are changing as applications run and life happens.
Remember the hey-day of Dial-Up when 56k was running really well and you could eek out 5kb/sec? Now imagine copying your entire RAM stack that way, while maxing out your CPU. Not a stealthy process…
So the good news here is that even if Spectre – the cross-VM exploit – is successfully leveraged, it will take a long time to capture significant chunks of memory, which would be the only way for the attacker to be sure of getting juicy bits. During that time, the victim VM is going to be burning a lot of CPU activity, which should catch someone’s attention long before a 4gb RAM stack could be fully inspected, let alone any larger volume of RAM.
If the attacker is smart though, they are inspecting data as they receive it, and stop the second they get something good. If they get lucky, and there are system passwords in the first few thousand bytes, the compromise may go undetected.
At the time of this post, March 26th, Microsoft, Intel, and Antivirus vendors have managed to get on the same page for most up-to-date Windows 10-era devices. Antivirus makers have incorporated the changes Microsoft needed, Intel has given Microsoft the code they needed, and Microsoft has pushed out the patches for Windows systems in the March patch cycle. The general guidance is the following, in order:
Here is a very simplified explanation as to why:
Microsoft’s March updates included Intel microcode updates for Spectre Variant 2 (CVE-2017-5715) for the newer CPU product lines – namely Skylake, Kaby Lake and Coffee Lake series processors – validating that they can deploy Intel microcode updates for consumers when they become available. This will help simplify the downstream deployment to consumers, as the updates will be applied automatically through Windows Update instead of requiring the extra step of directing the consumer to visit hardware manufacturers pages and search for updates.
The browser updates are to make sure that the latest protections are applied to keep malicious web code from using these exploits, and is, of course, just good practice for internet safety.
BIOS, chipset drivers, and firmware updates are an area where many fleet patch management systems fall down or are disregarded. It’s one thing to deploy a Windows update to your assets where the same update applies to all hardware. But if you have a few to dozens of different desktop and laptop manufacturers, generations, and hardware types in your environment, keeping BIOS versions current can be a full-time job by itself.
The fixes for Meltdown and Spectre are definitely an instance when you’ll want to make sure your BIOS and chipset firmware is kept up-to-date. Meltdown and Spectre made the hardware manufacturers take notice, and some fixes or mitigations may be included in BIOS updates, or software patches may require newer BIOS versions to properly interact with hardware. These are all good reasons to make sure that your workstation fleets have, in addition to the Microsoft updates, the latest BIOS versions, and chipset drivers. Even if it’s the only time this year, or within an asset’s lifecycle, updating your BIOS and chipset firmware is the one concrete thing you can do to stay ahead of these vulnerabilities.
Remember that Intel processors are used far and wide, and a lot of network technology and devices boil down to purpose-built computers running the same processors as workstations and servers. That means that there may be vulnerabilities yet to be found or fully explored in devices like routers, switches, firewalls, and load balancers that are based on Intel x86, 64bit or ARM processors. Most hardware in these classes handles traffic in dedicated hardware away from the device’s CPU. But given the overlaps of network technology and *Nix (which are extensive), keep an eye on your network and security appliance device patches over the coming year, especially perimeter-facing devices like firewalls and load balancers.
Protect Your Windows Devices Against Spectre and Meltdown, Microsoft Support, last updated March 23, 2018:
“This article discusses the impact of the recently disclosed processor vulnerabilities, named ‘Spectre’ and ‘Meltdown,’ for Windows customers. This article also provides resources to help keep your devices protected at home, at work, and across your enterprise.”
Mitigations Landing New Class Timing Attack, Mozilla Blog, January 4th, 2018:
Mozilla publishes a blogpost with information about the mitigations that were included in the latest build (57.0.4 as of Jan 4th). This is one of the more understated but important reactions to the news, as Mozilla was among the first to build in a fix preventing malicious websites and code from using the exploit. No muss, no fuss, just “let’s not let that thing happen”.
Update on Spectre and Meltdown Security Updates for Windows Devices, Windows Blog, March 1, 2018:
“Microsoft continues to work diligently with our industry partners to address the Spectre and Meltdown hardware-based vulnerabilities. Our top priority is clear: Help protect the safety and security of our customers’ devices and data. Today, I’d like to provide an update on some of that work, including Windows security update availability for additional devices, our role in helping distribute available Intel firmware (microcode), and progress driving anti-virus compatibility.”
Microsoft Released Spectre/Meltdown Patches for Surface Pro Devices, Tech Republic, March 20, 2018:
“Microsoft’s Spectre and Meltdown patch efforts continue, with the latest models of the Surface Pro now able to secure themselves.”
KVA Shadow: Mitigating Meltdown on Windows, Microsoft TechNet, March 23, 2018:
“The solution to this quandary is to, on transitions between kernel mode and user mode, also switch the processor’s address space between a kernel address space (which maps the entire user and kernel address space), and a shadow user address space (which maps the entire user memory contents of a process, but only a minimal subset of kernel mode transition code and data pages needed to switch into and out of the kernel address space). The select set of privileged kernel code and data transition pages handling the details of these address space switches, which are ‘shadowed’ into the user address space are ‘safe’ in that they do not contain any privileged data that would be harmful to the system if disclosed to an untrusted user mode application. In the Windows kernel, the usage of this disjoint set of shadow address spaces for user and kernel modes is called ‘kernel virtual address shadowing’, or KVA shadow, for short.”
Meltdown, Spectre, and the Costs of Unchecked Innovation, Wired, March 18, 2018:
“Spectre forced browsers to finally break the compatibility covenant of the web. It’s entirely likely that no meaningful projects relying on those features even exist, and even if they do, there may still be simple, safer workarounds. Nonetheless, such a prominent episode in which the internet broke its own code retroactively comes with a cost, at least ideologically. The web can’t quite be trusted as an infallible platform to the extent it had been.”
Interested in learning more about what you can do to address these vulnerabilities? Contact us to chat with John-Luke or one of our expert cybersecurity consultants today.