A non-technical synopsis of the microprocessor and kernel flaws associated with Spectre/Meltdown

By: Steve Kaun, RedTeam Security Consultant

Meltdown this. Spectre that. You might be hearing about these things in the news, or social media, or even from your tech-savvy friends. Meanwhile, the scale of this flaw appears to be affecting nearly every device manufactured within the past decade. What’s more is the level of confusion upon first disclosure. Seemingly, it was only Intel affected by the flaws within its processors’ microcode. However, throughout the day and the days that followed, Spectre was introduced and it pulled AMD, ARM, and Qualcomm microprocessors into the fray.

Fast forward the clock to today. The world watches and waits in hopes that this nightmare can be patched. Rumors and working code and theory continue to swirl about regarding mitigations, performance drops, and exploitability. Reviewing all the documentation surrounding the issue, it seems there is one clear answer in sight… patches are coming, and in a hurry.

As developers of applications, operating systems, and microprocessor microcode set to the monumental task of patching, we can appreciate this massive cause for alarm.

Meltdown

Starting with Meltdown, this was the first in the series of flaws within Intel’s (and possibly AMD, ARM, and Qualcomm) processor microcode in which an instruction within the processor known as “out-of-order” execution. This flaw resides entirely on the out-of-order execution to essentially break-out of the “userland” process’s mapped memory to reading kernel memory. This method, previous to the incoming patches, could bypass all protections of the host machine, include ASLR, anti-virus, kernel protections, as well as the CPU “privileged check bit”. The privileged check bit is what effectively sets kernel memory access.

At a high-level, Meltdown’s flaw can be summarized as the ability for userland applications to read all mappable memory content, including kernel protected addressed memory. That said, I still suggest giving the technical papers a review. When performing “out-of-order” execution, the CPU will attempt to predict and execute, but not commit to actual memory or registers. This, in effect, allows for rapid processing of data due to the processor attempting to prefetch and execute the dependency free instructions without actually performing a commit to memory. This effectively increases llel computing performance, but in doing so it adds the fatal flaw…

Meltdown: The Flaw

Suppose I developed an application, or binary, that’s sole purpose was to be executed. I don’t care about what level of OS permission I have, nor do I care about what software protections are in place. At execution, the application will force an exception within its execution sequence (Idk… divide by zero, doesn’t matter. Just hit the OS exception handler).

The instructions that follow are still problematically executed in advance and its resulting data is stored within the microprocessor’s cache, as well as the memory registers, but never committed. This exception is trapped by the exception handler that locks the kernel down and terminates the application. The issue from this is that follow-on code, without any dependencies, normally cannot access memory beyond its applications bounds. However, and more interesting, is that all prefetched executions are performed as if the “CPU Privileged Check Bit” was set to “true,”effectively executing the instructions and reading kernel addressed memory. Then by transmitting via side-channel attacks such as “Flush+Reload” time-based attacks, it is possible for an attacker to calculate the location of the unidentified caches.

Impact

Consequences from this are limited to what is contained within memory, however, this goes beyond your typical workstation. Meltdown can also cross the hypervisor isolation and read into the physical memory. Most impacted are datacenters, virtualization servers, and share webhosting. All it would take is one malicious actor to dump the entire server’s physical memory, which more likely than not contains secrets from other shared virtual servers.

Full memory disclosures are possible with this flaw.

Potential performance impacts from removing the out-of-order execution are speculative ranging from no impact, to upwards of up to 30% degradation of performance.

Threat Vectors

Applications / Executables
Malicious JavaScript / Web Applications
Local Non-Admin Users (Users with execute permissions)
Anything that can be executed to utilize the flaw, and also occupies userland

Recommendations and Mitigations

PATCH, PATCH, PATCH! Make sure you don’t miss a link in the chain before the microprocessor microcode updates are readily available. Apply relevant security patches for OS, and applications such as Chrome, Firefox, Netscape Navigator, and Safari.

Use a JavaScript blocker, this is due to an attack vector in the form of a malicious JavaScript since a browser meets criteria for enabling this attack.