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
Add your own comment

77 Comments on Intel CPUs Since Haswell Vulnerable to "Zombieload v2" Attacks, "Cascade Lake" Included

#26
Neverdie
New week, new intel vulnerability. Intel, we are dirty! :D
Posted on Reply
#27
er557
Welcom to tpu, @Neverdie , and nice nick, it represents a goal of mine...
Posted on Reply
#28
Dave65
Typical of Intel CPU's.. I am sure they will learn from their mistakes:/
Posted on Reply
#30
Camm
IMO, you would be crazy to buy an Intel CPU until their new architecture comes out around 2022.
Posted on Reply
#31
InVasMani
trparky
Add in all of the other various mitigations and patches and that number you quoted is much higher. I really have to wonder how much slower these chips are in actual real-world numbers with all of these mitigations in place.

It comes from the idea that with every single mitigation we have to implement its resulted in a loss of performance. Why is that? Is it perhaps because the chip wasn't doing something it should have been doing in the first place but was ignoring it for the sake of performance? We'll never know for sure. It's a conspiracy.
I was exaggerating heavily poking fun of Intel that by the time all of these "glued together" vulnerability fixes get done with and added up you'd end up with a CPU that's about 4% as capable as it was originally sold and marketed as to consumers.
Posted on Reply
#32
_UV_
I'am more and more starting to think all of this discovers here to help Intel gain more sells on newer "even more secure" products and force customers to phase out old still capable hardware faster. They don't care much about Westmere and Sandy, but Haswell and it's derivatives are still strong.
Posted on Reply
#33
zlobby
eidairaman1
When will intel learn?
They will TRULLY learn only when consumers and businesses start using ther brains instead of their wallets, i.e. not any time soon.

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.
Posted on Reply
#34
R-T-B
mtcn77
Who comes up with these mainstream gaming nomenclature.
The researchers, usually. NetCat in particulat is most likely a reference to the unix cat command, used to dump file contents.
Posted on Reply
#35
mtcn77
_UV_
I'am more and more starting to think all of this discovers here to help Intel gain more sells on newer "even more secure" products and force customers to phase out old still capable hardware faster. They don't care much about Westmere and Sandy, but Haswell and it's derivatives are still strong.
Definitely, there is a cultural appropriation going on.
R-T-B
The researchers, usually. NetCat in particulat is most likely a reference to the unix cat command, used to dump file contents.
Fine. But, Zombieload? Anybody remember the time Intel marketed Plants vs Zombies and made fun of F1 simulators?
Posted on Reply
#36
R-T-B
Vya Domus
What can they even do, it's becoming more and more evident that they simply had no security considerations whatsoever all these years when all of these things have been implemented.
Nearly no design from the era Skylake comes from does. They are all rooted in the same design era paradighms of being able to run "trusted code."

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.
mtcn77
Fine. But, Zombieload?
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"
Posted on Reply
#37
mtcn77
R-T-B
I really don't think Intel is trying to make these sound non-nefarious with names like "ZombieLoad"
They have a new department just for these kinds of things, you know. It is called Product Assurance and Security Group. What better way to sell an idea making it sound like a standalone product.
Posted on Reply
#38
R-T-B
mtcn77
They have a new department just for these kinds of things, you know. It is called Product Assurance and Security Group. What better way to sell an idea making it sound like a standalone product.
It sounds like marketing. Yeah, that happens. These names were still researcher chosen, that tends to be the case and yes, the researchers like attention thus they get sensational names.
Posted on Reply
#40
R-T-B
biffzinker
Your forgetting AMD has stated a couple of times when questioned if Ryzen was effected by they same Intel exploits that AMD didn't shortcut security for performance.
I don't buy into the idea any of these were "shortcuts"

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.
Posted on Reply
#41
mtcn77
R-T-B
I don't buy into the idea any of these were "shortcuts"

Skylake at it's core is a very tuned Sandy Bridge core. These types of cores were born in an era where everyone was doing things this way.

There is a reason meltdown also affected old arm chips, you know. But at least arm got off it's butt and introduced arm64.
You have it mistaken though - this isn't about the cores, rather that the address generator is affected. In essence, a seperate core that has been discreetly positioned outside of successive hardware generations. They'll need a completely new memory bus to move ahead. AMD is the better memory expert. We'll see how easily Intel deals with a major interference anyway, so don't take my word for it.
Posted on Reply
#42
R0H1T
R-T-B
These names were still researcher chosen, that tends to be the case and yes, the researchers like attention thus they get sensational names.
Or you know they were fans of Resident evil, TWD et al? I feel TV doesn't get the kind of recognition it deserves in the tech industry, not just this per se but lots of innovations in tech have been "telecast" on TV first.
Posted on Reply
#43
GreiverBlade
john_
New vulnerability for Intel CPUs? So what? Intel is throwing $$$$$ all over the Internet to inform us that their 6 core i5 dropped under $200(there are a number of articles all over the internet from multiple sites with almost identical title, informing about that). We should focus on that people, not that intel's CPUs are like swiss cheese.
R0H1T
Cascade Lake, brought to you by the makers of Swiss(?) Cheese - soon to be seen in a Microcenter near you :laugh:
good job putting a (?) .... because that expression is idiotic (but well in place thanks to ignorance), since between 2 Gruyere cheese, since initially the expression is about Gruyere cheese, the one that has the most hole in it is usually the fake French one lacking A.O.P and also lacking in taste.
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
Posted on Reply
#44
jgraham11
The Egg
The question that always comes to mind for me: Are AMD processors really any more secure, or are we just not aware of their vulnerabilities because they're under substantially less scrutiny, and much less testing is geared towards them?
Well, do you remember CTS Labs, a security firm from Israel that Intel "allegedly" paid hundreds of thousands if not millions to discover bugs in AMD systems. The only thing they came up with, (other than catchy names for the bugs, ei. RyzenFall) was a few really hard to implement, must have physical access to the computer type bugs, some of those chipset bugs also existed in Intel systems but Intel was not mentioned. Hardly compares to being hacked by visiting a website like with most Intel CPU bugs.

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??
Posted on Reply
#45
cucker tarlson
I measured 13% performance penalty in CPU bound gaming scenarios between Spectre/meltdown fixes on vs off.There's a big performance penalty on random write speed on my ssds too.Definitely have them disabled on broadwell cpus,dont know about others.
Posted on Reply
#46
yakk
Intel servers have been a hacker's dream for quite a while now...
Posted on Reply
#47
lexluthermiester
Having read the whitepaper pdf, in section 4 the required parameters of an attack vector once again require physical access to the target machine and being logged into an admin account(Windows or Linux). Remote attacks can not work. Once again, for the vast majority of average users, this is much ado about nothing...
Posted on Reply
#48
Solaris17
Dainty Moderator
R-T-B
Intel servers have been a hacker's dream for quite a while now...
Oh? you know that how? You are aware that the vast majority of servers are currently running on Intel right? Can you produce some white papers on the intrusions into hyper visors these have provided?

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.
Posted on Reply
#49
R-T-B
Solaris17
Oh? you know that how? You are aware that the vast majority of servers are currently running on Intel right? Can you produce some white papers on the intrusions into hyper visors these have provided?

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.
Why am I attributed to this?

No, they haven't, btw.

lexluthermiester
Having read the whitepaper pdf, in section 4 the required parameters of an attack vector once again require physical access to the target machine and being logged into an admin account(Windows or Linux). Remote attacks can not work. Once again, for the vast majority of average users, this is much ado about nothing...
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.
Posted on Reply
#50
lexluthermiester
R-T-B
Physical access is not needed. Admin is. Remote or not is irrelevant.
That is incorrect. Section4, the very first sentence reads as follows; "Following most side-channel attacks, we assume the attacker can execute unprivileged native code on the target machine"' This directly implies physical access by a logged in user. Additionally, in the paragraph "User-Space Leakage" it states that "In the cross-process user-space scenario, an unprivileged attacker leaks values loaded or stored by another concurrently running user-space application. We consider such a cross-process scenario most dangerous for end users. Many secrets are likely to be found in user-space applications such as browsers. The attacker is co-located with the victim on the same physical but a different logical CPU core, a common case for hyperthreading." Network users login using a different protocol than physical access users. The user-space parameters effect side-channel access adversely.

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.
Posted on Reply
Add your own comment