The Hurricane Labs Foundry: Volume 7, Spectral Meltdown

Welcome to another edition Hurricane Labs Foundry! I’m Tony Robinson, one of the security operations analysts at Hurricane Labs. The goal of this series is to inform readers about current security news and innovations to keep you aware of the latest threats and technology. Additionally, this series discusses various aspects of Splunk deployment, as well as observations and projects from the Hurricane Labs Security Operations Center.

The stories presented here are mostly short digests with links to source material in order for readers to get the full scoop, and additional context as required.

Please note: Tools, signatures, patches, resources, etc. that are linked to in this blog post are not the property of, and are in no way officially supported by Hurricane Labs. Remember to do your due diligence and test before deploying any new tools, signatures, patches, or countermeasures!

Spectre/Meltdown Fiasco

Note: This story is a pretty significant problem, so it is likely to take up a lot of the Foundry this time around because the effects are pretty far-reaching.

It has been a few days since Meltdown and Spectre, two massive security bugs that affect most modern CPUs today, have been announced. I chose to intentionally delay writing a blog post on this topic, because it was a very complex topic that I needed time to understand, and the implications of these bugs are going to be really far-reaching. Not only that, I wanted to see how everything started to play out.

This all started when three different groups of independent researchers discovered a set of critical issues affecting most ARM, Intel, and AMD CPUs since the mid 1990s (at least hypothetically). These vulnerabilities, are referred to as “Meltdown” and “Spectre”.

The heart of this issue lies in a technology used in most modern CPUs referred to as “speculative execution”, and “branch caching”. Essentially when a CPU is executing instructions and a “branch” (e.g. if/then statements, loops, etc.) is encountered, the CPU will take a guess as to which code path should be executed before the results of the if/then statement are evaluated. If the CPU’s guess is correct, then this results in a performance boost, because the CPU preemptively executed the instructions on the right code path. If the guess is incorrect, the executed instructions/results are “rewound”, and the correct code path is executed instead, but the results from the “guess” are stored in the CPU cache. Even if that execution would result in a memory access violation (e.g. reading memory from a location it shouldn’t have access to read), the code is still executed preemptively, and stored in the cache. The vulnerability “tricks” the speculative execution feature into reading memory the program being executed shouldn’t have access to, and reads the results stored in the CPU cache, effectively giving access to that memory.

Both Meltdown and Spectre allow users to read sensitive information from memory, but the difference is that the Meltdown vulnerability allows for reading kernel memory and/or processes from userland (e.g. ring 3 to ring 0 privilege escalation), while Spectre allows one userland process to read the memory contents of another userland process.

Security researcher Daniel Miessler has done an amazing job simplifying the complexity of these CPU-based bugs, and distilling the similarities and differences between those two vulnerabilities into a single blog post, with a nice infographic to boot.

So, that all sounds pretty complicated, but what’s the fallout? Who should care and why?

Does your organization use multi-tenant systems (e.g. VPS, “Cloud” infrastructure, etc.) where you share the same physical hardware? Spectre/Meltdown could impact your organization and allow secret information in memory (like passwords, private keys, etc.) to be read.

Does your organization use containers and/or VMs? These vulnerabilities do not care about virtual machine boundaries, allowing the container or VM to read memory from the physical system.

Lets say that you don’t used shared systems, VMs, or the cloud. Do you like to browse the web? A proof of concept for Meltdown/Spectre has been produced using Javascript. Websites can read process and kernel memory using these vulnerabilities. Fixes for both Mozilla Firefox, and Google Chrome (note that Google Chrome’s official patch is held off till January 23rd, but the “Site Isolation” feature, being touted as an effective mitigation, can be used in the meantime) have been announced to attempt to protect users from malicious websites attempting to exploit these vulnerabilities.

Do you use Intel CPUs? The proposed patch for Meltdown (the Intel-specific bug) could result in performance drops from 5% to as much as 60%. Phoronix is running a set of benchmarks for KPTI (the proposed fix to meltdown for the Linux kernel), and the benchmark results are… not optimal. Not to mention some people on social media are stating that cloud instances in AWS that never required upscaling (that is, the processing of automatically allocating adding CPU and other system resources to cloud instances), are suddenly starting to upscale to meet performance requirements, resulting in a 10-30% price hike in some heavily utilized AWS instances. Not only that, video game publisher Epic Games recently applied the meltdown patch to a production system for their popular “Fortnite” video game, resulting in a massive increase in CPU utilization.

Want to know what your CPU and/or software vendor is saying with regards to spectre/meltdown? BleepingComputer has done an amazing job of keeping up on responses from various vendors to help you determine what the impact of these vulnerabilities are to you and your organization. One thing that has come out in recent days that is NOT included in the list of advisories above is a potential issue with the Microsoft “meltdown” patches potentially impacting older AMD CPUs, resulting in systems that are unbootable.

In addition to all of this, it is suspected that the CEO of Intel, Brian Krzanich, sold off all of his company stock he was legally allowed to, while simultaneously being informed of this issue, and before the issue was made public. Arguments are being made that this potentially amounts to insider trading, since a very similar situation played out with the major credit union Equifax, with some of their top executives selling off company stock prior to publicly announcing their massive breach.

Even if the selling of the CEO’s stock is not ruled insider trading, it might have been a smart move on his part. Since this issue has been made public, several states in the US have begun the process of filing class action lawsuits against Intel with regards to this issue, and how it was handled, citing that the issue was known about in June of this year, and was only just recently patched. This in combination with several unhappy cloud providers and customers means that the legal and technological fallout from this issue may be far from over.