Starting in late December, the Linux kernel development lists started buzzing about some commits going into the kernel without the usual documentation that adjoins such code changes. When an AMD developer added some code on December 26th with the following comment, security researchers started zeroing in on the problem:
The code pointed to a problem in the way Intel CPUs were handling page table isolation (PTI). To understand how PTI was being abused, it’s helpful to have a basic explanation of how CPUs work.
A CPU or processor is the central computing module for a system. It does the mathematical functions at a very low level from microcode. A CPU runs internally at a certain clock speed while other components of the computer run at slower speeds. In terms of speed, the CPU is fastest, followed by memory, hard disk, and external sources. CPUs have been designed so that once something has been done it should be kept around in case it needs to be used again. To accommodate that, each CPU has its own cache of memory that runs at near-CPU speed. There are three caches in modern CPUs: L1, L2, and L3 cache. In addition, CPUs have now developed two technologies to allow them to move even faster: multi-core and multi-threading.
These technologies involve complex interaction with the CPU memory caches. Inside each processor core is a dedicated L1 cache (which is very small and very fast), an L2 cache (which is shared between CPU core pairs), and an L3 cache for the entire CPU die. Each subsequent cache is larger but slower with the L1 achieving near-CPU speed and L3 being the slowest. Anything not stored in the caches must go to system memory which runs significantly slower. The system keeps track of information stored in these caches through a series of nested tables called the Translation Lookaside Buffer (TLB). In memory, there are two types of permissions: kernel and user.
“Kernel” is the lowest level of the operating system that talks most directly to hardware and stores important information such as the password to your wi-fi and login credentials to the system. “User” stores information for normal unprotected data. Up until the patches associated with Meltdown and Spectre were released, any unprivileged process could determine the contents of protected memory by a series of educated guesses.
It’s Not Magic, But It Sure Seems Like It
Imagine I want to discover a piece of information you know regarding a deck of playing cards. We take a standard deck of 52 cards and have the dealer hold a copy of 10% of the cards or 5 cards. I can ask the dealer to show me any of the 52 cards at any time. I am going to time how long the dealer takes to show me a card. If I know my personal cache of information is empty, then I know anything I ask the dealer will either come from the cache that’s pre-seeded with kernel information or from the 47 cards on the table. If the dealer comes back with a card I ask for quickly, then I know it’s in his hand. If it takes longer, then they need to look at the table and find the card, load it from slower memory, and give it to me. From this I can make a series of educated guesses and find out what is actually in kernel memory without knowing directly what they have by just timing a series of samples.
So, What’s With the Names?
It seems like all major vulnerabilities get code names. Microsoft Developer Scott Hanselman even joked that he’s going to name the current CSS bug he’s chasing down “sassypants.”
— Scott Hanselman (@shanselman) January 4, 2018
“Spectre” is a play on the word speculative, referring to the speculative processing that is being exploited in CPU architecture. CPUs see a code decision ahead and start pre-compiling, building both branches of the code, and putting garbage in the cache but having it ready ahead of time. This speculative processing greatly increases processing speed as even heavily-loaded systems have a lot of spare time for the CPU to sit around and do nothing.
Spectre is associated with CVE-2017-5715 and CVE-2017-5753. Despite the original leak claiming AMD CPUs to be immune, they are also quite vulnerable to this attack. Sophisticated ARM processors are, as well.
The Meltdown attack is limited to Intel and ARM processors, but it’s the worse of the two attacks. Meltdown earns its name because it melts down the walls between kernel and user memory.
What’s Being Done to Fix the Vulnerabilities?
Both attacks, since they take place in the microcode within the actual processor, cannot be directly patched, flashed, or otherwise changed. Instead, operating system vendors have to make the commands to execute these flaws off limits. Kernel have been distributed for most modern operating systems with some noted problems. At the time of writing, Windows, MacOS, Linux, and VMware Hypervisors have all released patches in their supported operating systems. The initial patch provided by Windows has been deprecated in some AMD processors due to a problem causing blue screens which the team at Microsoft is blaming on wrong documentation on the part of AMD.
Some antivirus engines on Microsoft platforms had previously taken advantage of kernel flaws similar to those of Spectre and Meltdown and are currently crashing the operating system. Microsoft has a work-around involving only installing the patch where a certain registry key is installed.
For more information on what Fornetix is doing to combat Spectre & Meltdown, please click here.