Wednesday, January 3, 2018 [Tweets] [Favorites]

Intel CPU Design Flaw Necessitates Kernel Page Table Isolation

John Leyden and Chris Williams (tweet):

A fundamental design flaw in Intel’s processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.

[…]

Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we’re looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model.

[…]

Similar operating systems, such as Apple’s 64-bit macOS, will also need to be updated – the flaw is in the Intel x86-64 hardware, and it appears a microcode update can’t address it. It has to be fixed in software at the OS level, or go buy a new processor without the design blunder.

[…]

The fix is to separate the kernel’s memory completely from user processes using what’s called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

Tom Lendacky (via Hacker News):

AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

I wonder when Apple will have a macOS update and whether it will ship any Macs with AMD processors, depending on how long it takes Intel to develop a fix.

Ian King and Jing Cao (via Hacker News):

AMD shares surged as much as 7.2 percent to $11.77 Wednesday. Intel fell as much as 3.8 percent, the most since April, to $45.05.

[…]

The Santa Clara, California-based company’s chips have more than 80 percent market share overall and more than 90 percent in laptops and servers.

See also: The mysterious case of the Linux Page Table Isolation patches.

Update (2018-01-03): Alex Ionescu:

The question on everyone’s minds: Does MacOS fix the Intel #KPTI Issue? Why yes, yes it does. Say hello to the “Double Map” since 10.13.2 -- and with some surprises in 10.13.3 (under Developer NDA so can’t talk/show you).

The performance drop on a system with PCID is minimal. Most Macs have PCID.

Michael Larabel (via Hacker News):

I’ve been running some benchmarks and will have some more extensive tests soon, but given all the emails today about the issue, here are my initial benchmark numbers on two systems.

See also: MacRumors.

Update (2018-01-03): Intel (Hacker News):

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors[…]

At first, I didn’t like how they wrote this in such a way as to imply that AMD and ARM processors are among those affected, but apparently maybe they are.

See also: Pierre Lebeaupin.

Matt Linton and Pat Parseghian:

The Project Zero researcher, Jann Horn, demonstrated that malicious actors could take advantage of speculative execution to read system memory that should have been inaccessible. For example, an unauthorized party may read sensitive information in the system’s memory such as passwords, encryption keys, or sensitive information open in applications. Testing also showed that an attack running on one virtual machine was able to access the physical memory of the host machine, and through that, gain read-access to the memory of a different virtual machine on the same host.

These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running on them.

[…]

The Project Zero researchers discovered three methods (variants) of attack, which are effective under different conditions. All three attack variants can allow a process with normal user privileges to perform unauthorized reads of memory data, which may contain sensitive information such as passwords, cryptographic key material, etc.

@FioraAeterna:

oh, and one last thing: the thing that gets me most about this exploit is it isn’t really a single exploit, it’s a whole category of exploits. verifying that no further attacks exist sounds EXTREMELY hard.

See also: Hacker News.

Juli Clover:

ARM and AMD have both issued statements following Intel’s press release. AMD says there is a “near zero risk” to AMD processors at this time, while ARM says its processors are vulnerable.

Update (2018-01-04): Meltdown and Spectre:

These hardware bugs allow programs to steal data which is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs. This might include your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents.

Meltdown and Spectre work on personal computers, mobile devices, and in the cloud. Depending on the cloud provider’s infrastructure, it might be possible to steal data from other customers.

ARM (archive, Hacker News):

The majority of Arm processors are not impacted by any variation of this side-channel speculation mechanism. A definitive list of the small subset of Arm-designed processors that are susceptible can be found below.

Via Bob Burrough:

Arm’s response is downright misleading.

Microsoft Azure:

The majority of Azure infrastructure has already been updated to address this vulnerability. Some aspects of Azure are still being updated and require a reboot of customer VMs for the security update to take effect.

Troy Wolverton:

Intel CEO Brian Krzanich sold off $24 million worth of stock and options in the company in late November.

[…]

Intel says the stock sale was unrelated to the vulnerability, but came as part of a planned divestiture program. But Krzanich put that stock sale plan in place in October — several months after Intel was informed of the vulnerability.

Linus Torvalds (via The Register):

I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be written with “not all CPU’s are crap” in mind.

Or is Intel basically saying “we are committed to selling you shit forever and ever, and never fixing anything”?

Aaron Pressman (via Alex Ionescu):

AMD said its chips were affected by some but not all of a series of related security exploits uncovered by researchers. AMD has already developed a simple software fix for its chips that will not impact PC performance, an AMD spokesman said. “Due to differences in AMD’s architecture, we believe there is a near zero risk to AMD processors at this time,” the company said in a statement. “We expect the security research to be published later today and will provide further updates at that time.”

Microsoft Edge Team (via Steve Troughton-Smith):

These techniques can be used via JavaScript code running in the browser, which may allow attackers to gain access to memory in the attacker’s process.

[…]

Initially, we are removing support for SharedArrayBuffer from Microsoft Edge (originally introduced in the Windows 10 Fall Creators Update), and reducing the resolution of performance.now() in Microsoft Edge and Internet Explorer from 5 microseconds to 20 microseconds, with variable jitter of up to an additional 20 microseconds. These two changes substantially increase the difficulty of successfully inferring the content of the CPU cache from a browser process.

Mozilla (Hacker News):

Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox.  This includes both explicit sources, like performance.now(), and implicit sources that allow building high-resolution timers, viz., SharedArrayBuffer.

Chromium (via Yehuda Katz):

Chrome allows users to enable an optional feature called Site Isolation which mitigates exploitation of these vulnerabilities. With Site Isolation enabled, the data exposed to speculative side-channel attacks are reduced as Chrome renders content for each open website in a separate process.

[…]

Don’t serve user-specific or sensitive content from URLs that attackers can predict or easily learn. Attackers can load such URLs in their attack pages (e.g. <img src="https://email.example.com/inbox.json"/>) to get the sensitive information into the process rendering their page, and can then use out-of-bounds reads to discover the information. Use anti-CSRF tokens and SameSite cookies, or random URLs to mitigate this kind of attack.

Kevin Beaumont:

Okay there is another VERY IMPORTANT THING with Microsoft Meltdown patches - “Customers will not receive these security updates and will not be protected from security vulnerabilities unless their anti-virus software vendor sets the following registry key”

Joe Armstrong:

I think I might have said now and again that

“shared memory is the root of all evil”

now I should add

“Shared memory is the root of all security problems”

Aras Pranckevičius:

“Retpoline”, an optional compiler flag to deal with Spectre attack…. Landing to llvm/gcc as we speak. Virtual calls, as well as switch statements etc., are about to get more expensive.

Here’s the Hacker News thread about the LLVM patch.

Jacek Galowicz (Meltdown paper, PDF):

This kind of speculative execution does not only occur over branches: When a program accesses a specific cell of memory, the processor needs to decide if it is allowed to do so by consulting the virtual memory subsystem. If the memory cell has previously been cached, the data is already there and data is returned while the processor figures out if this access is legitimate. With speculative execution, the processor can trigger actions depending on the result of a memory access while working to complete the corresponding instruction.

If the memory access was not legitimate, the results of such an instruction stream need to be discarded, again. For a user application it is not possible to access the final result of any computation relying on such an illegitimate memory access. The interesting crux of this is that although retirement is correctly performed, all speculatively executed and then discarded instructions have still left some measurable effect on the cache subsystem…

[…]

While none of these spots contains anything useful before or after this sequence of machine code instructions, it is possible to make sure that the whole user space array is completely uncached/cold before executing them. After trying to execute them, it is necessary to recover from the page fault that the processor reacts with. But then, one of the spots in the user space array remains cached!

Finding out the offset of the cached/warm spot of memory in the user space array allows for calculating the actual value that was read from memory, which can be done by measuring access timings on each of the 256 spots that could have been touched by the speculative execution.

Spectre paper (PDF):

Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim’s confidential information via a side channel to the adversary. This paper describes practical attacks that combine methodology from side channel attacks, fault attacks, and return-oriented programming that can read arbitrary memory from the victim’s process. More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/side-channel attacks. These attacks represent a serious threat to actual systems, since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices.

See also:

Update (2018-01-05): See also:

Update (2018-01-08):mikeymikey:

Apple JUST updated today (Jan 5th) and REMOVED mention of 10.12 and 10.11 being fixed for CVE-2017-5754 aka #Meltdown

Only 10.13.2 contains the fix.

Juli Clover:

Apple today confirmed that it has addressed the recent “Meltdown” vulnerability in previously released iOS 11.2, macOS 10.13.2, and tvOS 11.2 updates, with additional fixes coming to Safari in the near future to defend against the “Spectre” vulnerability.

Zac Hall (Hacker News):

Apple has released an update to macOS High Sierra for all Macs running macOS 10.13.2. The supplemental security update likely addresses the Spectre flaw that affected Safari and may contain further mitigations for Meltdown.

Jon Masters:

At Red Hat, we’ve been working on mitigations for potential attacks under standard industry security embargos, deploying small, targeted teams operating on a “need to know” basis in order to prepare ahead of public disclosure. I was fortunate enough to be co-leading our efforts at mitigation of Meltdown and Spectre, alternatively known as variants 1, 2, and 3 of a family of similar attacks disclosed by Google Project Zero in a blog post on January 3rd. In the course of our efforts, we reproduced Meltdown (variant 3) in our labs, and examined other variants, while working alongside many of our trusted hardware partners on mitigations.

While we have a solid understanding of these vulnerabilities and the current analysis of the contributing factors as well as patches to mitigate their potential impact, we will continue to collaborate with our partners, customers and researchers on this situation. Additionally, we would like to help others to understand these complex issues, ideally using language and terms that don’t require the reader to be in the chip design business.

See also:

Update (2018-01-09): Andy Greenberg:

Yet when Intel responded to the trio’s warning—after a long week of silence—the company gave them a surprising response. Though Intel was indeed working on a fix, the Graz team wasn’t the first to tell the chip giant about the vulnerability. In fact, two other research teams had beaten them to it. Counting another, related technique that would come to be known as Spectre, Intel told the researchers they were actually the fourth to report the new class of attack, all within a period of just months.

“As far as I can tell it’s a crazy coincidence,” says Paul Kocher, a well-known security researcher and one of the two people who independently reported the distinct but related Spectre attack to chipmakers. “The two threads have no commonality,” he adds. “There’s no reason someone couldn’t have found this years ago instead of today.”

Gil Tene (via Hacker News):

PCID is now a critical feature for both security and performance.

Ezequiel Bruni (via Matt Birchler):

Even if we did magically get perfect fixes for the Meltdown and Spectre problems, this is going to spark a larger conversation about security and JavaScript in particular. I mean, what other bits of hardware could be compromised by a simple web page? This could happen again. No, to hell with that. This will happen again.

Filip Pizlo:

Spectre impacts WebKit directly. Meltdown impacts WebKit because WebKit’s security properties must first be bypassed (via Spectre) before WebKit can be used to mount a Meltdown attack.

[…]

This document explains how Spectre and Meltdown affect existing WebKit security mechanisms and what short-term and long-term fixes WebKit is deploying to provide protection against this new class of attacks.

This is a great write-up.

See also: CommitStrip (via Andy Bargh).

Update (2018-01-11): See also:

Update (2018-01-14): Jérôme Segura:

Online criminals are notorious for taking advantage of publicized events and rapidly exploiting them, typically via phishing campaigns. This particular one is interesting because people were told to apply a patch, which is exactly what the crooks are offering under disguise.

Marcel Weiher:

I just retested the stock mkfile after the meltdown patch, and I/O rates are now down to a measly 61.5MB/s, measured both by wall-clock (well, time) and iostat. That's actually 1/4 the throughtput measured before, but the new timing is also with APFS enabled. Using large buffers to minimize the number of sys calls and presumably effectively eliminates the meltdown penalty shows the maximum throughput with APFS to be reduced by about 20% compared to before, to 1.6GBs.

Update (2018-01-15): Cameron Kaiser:

Tip of the hat to miniupnp who ported the Spectre proof of concept to PowerPC intrinsics. I ported it to 10.2.8 so I could get a G3 test result, and then built generic PowerPC, G3, 7400, 7450 and G5 versions at -O0, -O1, -O2 and -O3 for a grand total of 20 variations.

Jean-Louis Gassée:

It now appears that “in principle” trouble with microprocessors was understood more than 20 years ago. In a 1995 paper titled The Intel 80x86 Processor Architecture: Pitfalls for Secure Systems, authors Sibert, Porras, and Lindell described architecture subtleties and implementation errors that made many x86 processors undesirable for secure systems. In particular, the paper’s authors pointed to memory architecture flaws that allow unwanted peeks into “protected” processes — precisely the sort of trouble that we’re seeing today.

The concern that Sibert et al expressed decades ago and its realization as Meltdown and Spectre should shake our old habits of the mind. We’ve come to believe that while software is a petri dish of deadly germs, the CPU is a reliable, antiseptic “hard truth”.

See also: Adrian Colyer.

Update (2018-01-19): Bloomberg:

In 2013, a teenager named Jann Horn attended a reception in Berlin hosted by Chancellor Angela Merkel. He and 64 other young Germans had done well in a government-run competition designed to encourage students to pursue scientific research.

In Horn’s case, it worked. Last summer, as a 22-year-old Google cybersecurity researcher, he was first to report the biggest chip vulnerabilities ever discovered.

Update (2018-01-22): See also: Linus Torvalds (Slashdot, Hacker News) and Bloomberg (Hacker News).

Update (2018-01-23): Juli Clover:

Along with macOS High Sierra 10.13.3, Apple this morning released two new security updates that are designed to address the Meltdown and Spectre vulnerabilities on machines that continue to run macOS Sierra and OS X El Capitan.

13 Comments

“Most Macs have PCID.”

Maybe “most Macs on sale now”. But surely not most Macs in use.

It should be noted that this is far larger than Intel CPU's and KPTI, and has far deeper implications than folks seem to be currently understanding.

I mean, really, everything and everyone is currently borked.

Just for one example, as best as I can tell, there is currently no safe way to run any browser on any OS with JavaScript enabled. And full-spectrum browser patches won't be here today, or tomorrow, or the next day, or the next week.

(The best OpSec you can do is to only enable JS in your browser for a single site on a need basis, and to approve every domain request from that site by hand with Little Snitch, based on what sources you think are trustworthy.)

This is most "interesting" thing to happen to popular computing since, well, I can't think of a precedent.

"while ARM says its processors are vulnerable"

What about Apple processors?

@Chucky Yeah, this is really amazing.

@someone I haven’t heard anything definitive about Apple’s ARM processors yet, but I would assume they are affected as well.

And Intel taking cheap shots at AMD. When AMD aren't even vulnerable to two variants and one is a simple software fix.

Adrian O'Connor

I'm guessing that the most recent Sierra update 10.12.6 doesn't include the fix, and that Apple probably aren't going to patch it :( Certainly I can't see anything about it, though Apple still haven't updated their release notes for 10.13 to include the info about this particular security flaw, because of the policy around disclosure.

I was going to sit out 10.13, since 10.12 has been stable and was doing just fine, but I think I might need to re-evaluate that plan now and free up some time (and space) to do the upgrade...

@Michael Well, iPhone, iPad and Apple TV devices are affected too. https://support.apple.com/en-us/HT208394

@Adrian 10.12.6 is said to include a fix.

@someone "10.12.6 is said to include a fix."

10.12.6 is no more said to include the fix.

Because Apple is just unable to deliver a clear message.

Let's also not forget to wonder why the fixes for the all these flaws are not available yet (in Safari for instance when the patches are available in other web browsers).

[…] updating to macOS 10.13 is currently the only way to get Apple’s Meltdown security […]

@Chucky: that's true and all, but 99% of people don't care as long as they can still watch cat videos on facebook. :)

I imagine "Security Update Developer Beta 2018-001" fixes Meltdown on 10.12.6 but of course Apple seems to have provided it with zero details. :(

[…] Previously: Intel CPU Design Flaw Necessitates Kernel Page Table Isolation. […]

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment