Communications of the ACM
"when Performance Is Pursued Above All"
The first researcher known to demonstrate the vulnerabilities privately alerted chipmakers last June; a planned public announcement was undercut by a Jan. 2 news report.
Credit: Natascha Eibl
The New Year began with disclosures of major security flaws in microprocessors used in personal computers, cellphones, and data centers. The risks were only recently recognized, although they arise from speed-boosting tricks used for decades.
"This vulnerability demonstrates what happens when performance is pursued above all," said security expert Bruce Schneier.
Hardware and software vendors have since been scrambling to roll out patches, but their performance impact remains unclear.
The first researcher known to demonstrate the vulnerabilities was Google's Jann Horn, who privately alerted Intel, AMD, and ARM in June 2017. Several other research teams later found the problem and joined with Horn and various companies under the "responsible disclosure" framework. This response was complicated by the disclosure of the issue in a January 2 story in The Register, a week ahead of a planned public announcement.
The design features that enable the attacks have been used since the 1990s, but near-simultaneous discovery of bugs is not unusual, Schneier said. Nonetheless, he said, "we have no idea if the NSA, or any other country, has exploited this vulnerability" during its long existence.
The various versions of the malicious code all exploit an architecture that executes some code before its legitimacy is guaranteed, keeping the processor busy while needed data is retrieved from memory. If an instruction should not have been executed, its results are ignored, but it leaves behind changes in the state of the chip that can be probed using various "side-channel" techniques. For example, a malicious program can tell if a requested block of data has already been copied into cache memory because it is re-accessed much faster.
Horn described three variants, but the other researchers group these into two types, which they call Meltdown and Spectre.
Meltdown exploits design features found in most Intel processors and some ARM designs but apparently no AMD processors. On vulnerable chips, instructions that are being executed out-of-order can temporarily access memory locations that should be viewable only by operating-system processes running in "kernel mode." Those locations "typically include the whole physical memory of the computer, because kernel mode is generally considered to basically be God," said Spectre co-discoverer Paul Kocher, who recently stepped back from a management role at Rambus to explore chip security more deeply.
Such forbidden access eventually leads to an exception that terminates the rogue process and discards its data. However, data it had stored in cache memory, for example, can be probed by a second process to reveal passwords and other data, even from other users in a cloud-computing center.
"You don't have to know anything about the software running on the computer," Kocher said. "Meltdown is a very serious threat."
Fortunately, separating user and kernel memories effectively limits the risk, although it imposes a performance penalty for swapping between user and kernel processes.
In contrast to Meltdown, Spectre is hard to implement, but "comparing it with a lot of things people regularly exploit," Kocher said, "it's actually comparable or easier." Moreover, a wide range of computer and cellphone chips are vulnerable, and fixes that preserve performance are harder to devise.
Spectre takes advantage of a widely-used speed enhancement called speculative execution, in which the processor guesses which branch of a conditional a program will follow and begins executing those instructions while it fetches the data needed to decide. As with Meltdown, this process leaves measurable traces even if the calculations are abandoned. Programmers might avoid the problem by forcing all conditionals that might pose a security risk to execute in order, but this would degrade performance. Moreover, this approach is tedious and "very hard to test, because if you make a mistake your code still functions just fine," Kocher said.
Despite the chaotic rollout, vendors have responded rapidly to the new threat, thanks to months of preparation. For example, Terry Myerson of Microsoft wrote on January 9 that the software giant already offered patches for 41 of the 45 Windows versions it supports, although some users will notice a speed hit. Nonetheless, experts urge security-sensitive users to install upgrades as soon as they are available.
Ultimately, addressing this new class of exploits will require redesigning chips. Kocher thinks this problem highlights a need to renegotiate the contract between software and hardware developers to clarify the responsibility for all exploitable changes in hardware state, not just the final results. "What the programmer is writing, even in assembly language, is a fiction that doesn't accurately reflect what's happening in the hardware," he said.
Indeed, Intel's initial response emphasized that the chips were "operating as designed," which may actually be the problem.
Don Monroe is a science and technology writer based in Boston, MA.
No entries found