Wednesday, November 13th 2019
Intel CPUs Since Haswell Vulnerable to "Zombieload v2" Attacks, "Cascade Lake" Included
All Intel CPU microarchitectures since 2013 are vulnerable to a new class of "Zombieload," attacks, chronicled under "Zombieload v2" (CVE-2019-11135). This is the fifth kind of microarchitectural data sampling (MDS) vulnerability, besides the four already disclosed and patched against in Q2-2019. The vulnerability was kept secret by the people who discovered it, as Intel was yet to develop a mitigation against it. There is no silicon-level hardening against it, and Intel has released a firmware-level mitigation that will be distributed by motherboard manufacturers as BIOS updates, or perhaps even OS vendors. While Intel's latest enterprise and HEDT microarchitecture, "Cascade Lake" was thought to be immune to "Zombieload," it's being reported that "Zombieload v2" attacks can still compromise a "Cascade Lake" based server or HEDT that isn't patched.
"Zombieload v2" is an exploitation of the Asynchronous Abort operation of Transactional Synchronization Extensions (TSX), which occurs when malware creates read operation conflicts within the CPU. This reportedly leaks data about what else is being processed. "The main advantage of this approach is that it also works on machines with hardware fixes for Meltdown, which we verified on an i9-9900K and Xeon Gold 5218," reads the latest version of the Zombieload whitepaper that's been updated with "Zombieload v2" information. TSX is a requisite for "Zombieload v2," and all Intel microarchitectures since "Haswell" feature it. AMD processors are inherently immune to "Zombieload v2" as they lack TSX. Intel downplayed the severity or prevalence of "Zombieload v2," but dispatched microcode updates flagged "critical" nevertheless.
Source:
ZDNet
"Zombieload v2" is an exploitation of the Asynchronous Abort operation of Transactional Synchronization Extensions (TSX), which occurs when malware creates read operation conflicts within the CPU. This reportedly leaks data about what else is being processed. "The main advantage of this approach is that it also works on machines with hardware fixes for Meltdown, which we verified on an i9-9900K and Xeon Gold 5218," reads the latest version of the Zombieload whitepaper that's been updated with "Zombieload v2" information. TSX is a requisite for "Zombieload v2," and all Intel microarchitectures since "Haswell" feature it. AMD processors are inherently immune to "Zombieload v2" as they lack TSX. Intel downplayed the severity or prevalence of "Zombieload v2," but dispatched microcode updates flagged "critical" nevertheless.
77 Comments on Intel CPUs Since Haswell Vulnerable to "Zombieload v2" Attacks, "Cascade Lake" Included
In the table, updates are ordered from highest overall severity rating to lowest to give you a sense of how to prioritize deployment.
www.guru3d.com/news-story/intel-will-be-addressing-77-security-vulnerabilities-this-month.html
But your question runs deeper - when will people learn? With the root-of-trust laying solely in intel's hands (or any other manufactirer for that matter) there would be no such thing as true security. We need a paradigm shift.
AMDs Ryzen has a lot of those designs too, but is largely understudied. Still, being newer, it's not surprising it's doing better and only has Spectrev2 so far
Everyone really needs to start at the drawing board, but understandably, no one wants to, especially if it will just perform worse.Also the researchers proposed name, as the MDS vulnerability whitepaper states.
I really don't think Intel is trying to make these sound non-nefarious with names like "ZombieLoad"
Foreshadow
www.amd.com/en/corporate/product-security#Current-Security-Updates
Skylake at it's core is a very tuned Sandy Bridge style design. These types of cores were born in an era where everyone was doing things this way. It wasn't a "shortcut," it was a design assumption that you could trust your code.
It gave us such things as speculative execution, which AMD also utilizes but aparently has done some level of tweaking to harden.
There is a reason meltdown also affected old arm chips, you know. But at least arm got off it's butt and introduced arm64.
rarely any hole in a Swiss cheese.... we do not cheap out on the total mass!
other than that, about the news .... "ohhhhh looook... i didn't expect that at all!" (sarcasme ofc) is the effect
funny in the end that anything that gave Intel an edge is turning out to be a vulnerability ....
oh, well... that comfort me in thinking a R5 3600/3600X or R7 3700/3700X are more desirable than a 9900KS
If there were any actual bugs, believe it that Intel would make us aware of it, it would be on the news, on the radio warning people about it. Doesn't it seem weird that all these Intel CPU bugs haven't made the main stream media: news, radio, TV, etc.... Intel has even come out and said to disable Hyper-Threading in all but their latest CPUs, shouldn't the general public know about this??
Its just you know, I know that alot of these cloud providers run on clusters and these nodes carry the weight of VMs with tasks being distributed to them. So while its super cool that a mere 48 bits of memory of god knows what can in a lab be gleaned from a VMs memory address space via the host. Iv yet to see anyone perform the experiment on other hypervisors or in the type of environment most of these large services run in.
I'll standby. Thank you.
No, they haven't, btw.Physical access is not needed. Admin is. Remote or not is irrelevant.
This may be not much, but again, another tool for the malware toolbox.
Such requirements need physical access in the initial stage of any attack, whether by fully executing the attack in physical presence or by starting the attack with physical presence and handing off to a remote user. Regardless of the following stages of any attack, the use of this vulnerability requires physical access to the machine being attacked.