SoylentNews is people
SoylentNews
UPDATE 2: (martyb)
This still-developing story is full of twists and turns. It seems that Intel chips are definitely implicated (AFAICT anything post Pentium Pro). There have been various reports, and denials, that AMD and ARM are also affected. There are actually two vulnerabilities being addressed. Reports are that a local user can access arbitrary kernel memory and that, separately, a process in a VM can access contents of other virtual machines on a host system. These discoveries were embargoed for release until January 9th, but were pre-empted when The Register first leaked news of the issues.
At this time, manufacturers are scrambling to make statements on their products' susceptibility. Expect a slew of releases of urgent security fixes for a variety of OSs, as well as mandatory reboots of VMs on cloud services such as Azure and AWS. Implications are that there is going to be a performance hit on most systems, which may have cascading follow-on effects for performance-dependent activities like DB servers.
To get started, see the very readable and clearly-written article at Ars Technica: What’s behind the Intel design flaw forcing numerous patches?.
Google Security Blog: Today's CPU vulnerability: what you need to know.
Google Project Zero: Reading privileged memory with a side-channel, which goes into detail as to what problems are being addressed as well as including CVEs:
So far, there are three known variants of the issue:
- Variant 1: bounds check bypass (CVE-2017-5753)
- Variant 2: branch target injection (CVE-2017-5715)
- Variant 3: rogue data cache load (CVE-2017-5754)
Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at:
During the course of our research, we developed the following proofs of concept (PoCs):
- A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.
- A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]
- A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)
- A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.
According to a report in Barron's:
AMD said through a spokesperson:
There is a lot of speculation today regarding a potential security issue related to modern microprocessors and speculative execution. As we typically do when a potential security issue is identified, AMD has been working across our ecosystem to evaluate and respond to the speculative execution attack identified by a security research team to ensure our users are protected.
To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD’s architecture, we believe there is a near zero risk to AMD processors at this time. We expect the security research to be published later today and will provide further updates at that time.
UPDATE 1: (takyon)
Original story follows
It appears that all modern Intel processors contain a hardware-level security flaw. Details are being suppressed while patches are developed, but it appears that a user process can put a reference to a privileged address in speculative execution, and thereby bypass privilege restrictions.
Since simply marking certain areas of the virtual memory space as privileged is insecure, operating systems will have to completely isolate their kernels, i.e., remove them from the virtual memory space of user processes. This will make context switching more expensive. Presumably, every OS call will now require swapping out the virtual memory map and flushing the page tables cache in the processor. Twice: one to go to the kernel, and once to return to the user process. This will be a significant performance hit: depending on the application, up to 30%.
This is apparently an Intel-specific bug; processors by other manufacturers are not affected. However, they may still suffer the performance hit: The changes to the OS are substantial, and it seems unlikely that OS manufacturers will, in the long-term, maintain two completely different kernel-access strategies for different processors.
Previously: Major Hardware Bug Quietly Being Patched in the Open
A bug that affects Intel processors requires Kernel Page Table Isolation in order to be mitigated:
It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.
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.
The fix could dramatically lower performance for some workloads:
The Python Sweetness blog, which first reported on the bug, said the vulnerability was first identified by developers working on the Linux kernel, though it also affects Windows operating systems. It added that a number of major security patches for the Linux kernel have been pushed out over the Christmas and New Year holidays, which are likely to be an attempt to fix the new bug. These kernel updates have provided a workaround that can prevent attackers from exploiting the bug, but the problem is that doing so comes at a heavy cost. In technical terms, the fix involves using Kernel Page-Table Isolation or PTI to restrict processes so they can only access their own memory area. However, PTI also affects low-level features in the hardware, resulting in a performance hit of up to 35 percent for older Intel processors.
[...] "Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November," the Python Sweetness blog reported Monday. "In the worst case the software fix causes huge slowdowns in typical workloads." These slowdowns were highlighted by Brad Spengler, lead developer of grsecurity, which is a set of patches for the Linux kernel which emphasize security enhancements. According to HotHardWare, Spengler said an Intel Core i7-3770S GPU will take a 34 percent performance hit, while the new Intel Core i7-6700 will run 29 percent slower.
The Linux fix can be disabled, which you will likely want to do if you use an AMD processor.
December 19, 2017: Intel's CEO Just Sold a Lot of Stock
Did Krzanich use that money to buy AMD stock?
[See also: How-To Geek, Phoronix, and Security Week. --martyb]
An Anonymous Coward contributed Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR.
(Score: 3, Informative) by takyon on Wednesday January 03 2018, @08:57PM (7 children)
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ [intel.com]
https://www.barrons.com/articles/intel-refutes-chip-bug-inaccurate-media-reports-1515010736 [barrons.com]
https://www.bloomberg.com/news/articles/2018-01-03/intel-says-research-showed-design-element-created-vulnerability [bloomberg.com]
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 5, Insightful) by Justin Case on Wednesday January 03 2018, @09:32PM (1 child)
Wow the spin is heavy in that one!
See? It's not just us! Other companies have been... made aware. Oh. Nevermind.
Nothing to see here. We designed this flaw, so everything's OK.
In other news, it is utterly false that Martians landed on the White House lawn this morning. Oh, wait -- that wasn't ever claimed? But, you have to admit, it is still utterly false that Martians landed on the White House lawn this morning.
No, the exploit (maybe) lets the attacker discover secrets. Then the attacker can do other badness using those secrets. What badness? Who knows? Maybe even land on the White House lawn!
This is an "if" statement with two parts separated by an "and". One part may be false, so the compound condition is false. But they want you to assume both parts are false.
Yeah, so committed we allowed this to happen and never discovered, reported, or fixed it for $MANY years. The "we are committed" is standard language whenever someone gets caught with their pants down. It is non-measurable and meaningless.
I am committed to world peace. Now, where did I leave my red button that is bigger than Trump's or North Korea's?
(Score: 1) by pTamok on Wednesday January 03 2018, @10:55PM
I agree that Ashes-winning amounts of spin have been used.
The point is that a user-mode (Ring-3) program should not be able to see kernel-mode (Ring-0) data*. Exposing 'sensitive' data is basically game-over, security wise if, for example, that sensitive data is an encryption key or a password.
There were probably exigent reasons for Intel to make this (among many) poor design choices in the history of the x86 architecture, but it is yet another excellent example of why having a hardware (or software) monoculture is a bad idea.
Also, working as designed, does not mean the design is correct. No doubt the BSDs will need to make some changes, and if there are any, any O/S that is meant to be security assured on the x86 (or 64-bit ARM) may need to re-evaluate the correctness of their assumptions.
(Score: 2, Informative) by Anonymous Coward on Wednesday January 03 2018, @10:15PM (3 children)
To be fair to Intel, it is informed speculation at this point. First we have the Gruss paper: [gruss.cc]
A good assumption here is that they're talking about the x86 ISA. Then we have Tom Lendacky's patch: [lkml.org]
That says this specific issue is not the ISA and not limited to the ISA prefetch instruction which (presumably) could be patched via microcode but is limited to Intel chips. This leaves automatic prefetch as a result of branch prediction and speculative execution with the (assumed) bug being that information is available in cache despite a page table fault. It is not an unreasonable assumption for people to have made based on the available evidence. The KASLR issue is separate from this specific bug although it comes from the same batch of papers. [gruss.cc]
(Score: 2) by shortscreen on Thursday January 04 2018, @05:35AM (2 children)
How does information being in the cache become available to user code? I don't know of any way to directly read the cache or dump its contents to my own buffer. Or, once it's in the cache, does that mean attempting to read it a second time (for real) will succeed without triggering a page fault?
(Score: 0) by Anonymous Coward on Thursday January 04 2018, @10:16AM
If you ever bought flat pack furniture you know the answer; "some assembly required". The linked paper details side-channel timing attacks against KASLR, this in turn enables control flow hijacking and code reuse attacks. I don't think the story of the prefetch issue stops here and the mitigation patches add more 0xCR3 gadgets.
(Score: 2, Informative) by Anonymous Coward on Thursday January 04 2018, @01:31PM
The trick is that the data is not just in the cache, it is also available in the program during speculative execution.
So you need to execute further code that produces an effect even if the speculative execution is later canceled.
That further code is an indirect memory load.
Something like (very simplified!)
if (variable_that_is_false_but_CPU_assumes_to_be_true) {
unsigned char value = *kernel_address_pointer;
volatile int a = huge_array[value*64];
}
Now you "just" have to check which part of huge_array ended up in the cache and you know what data was fetched into "value" during the speculative execution...
(Score: 1, Informative) by Anonymous Coward on Thursday January 04 2018, @05:16AM
https://www.theregister.co.uk/2018/01/04/intels_spin_the_registers_annotations/ [theregister.co.uk]