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

[btarunr]

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.



View at TechPowerUp Main Site

 

[londiste]

AMD processors are inherently immune to "Zombieload v2" as they lack TSX, but come with an analogous (though incompatible) feature called Advanced Sync Facility (ASF).

Sidenote - no they don't. ASF has been developed but no CPUs come with it.

Zombieload v2 is kind of a curious case. When Zombieload was announced/revealed researchers did say Cascade Lake and co were also affected and pointed at TSX at enabling that. Intel vehemently denied this which was expected but there was little revealed in way of details. Apparently, now that Intel got some type of mitigation the time for details is here.

TSX has been recommended to be disabled in any security-conscious environment for a while and even more so since Zombieland thing.

 

[btarunr]

Sidenote - no they don't. ASF has been developed but no CPUs come with it.

Thanks, updated.

 

[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

 

[dorsetknob]

There is no silicon-level hardening against it,

another Security Failure from intel they sure cascade from Intel or is that domino roll.

 

[ratirt]

another Security Failure from intel they sure cascade from Intel or is that domino roll.

Well, with Intel's security these days is like a sleigh ride of the Guadalupe peek

 

[ncrs]

This is not even the worst part of this month's Intel vulnerability disclosures. The Jump Conditional Code (JCC) erratum affects everything from Skylake and is mitigated in the microcode. There is a considerable performance penalty that is visible in every type of software. By their own admission it's going to have a 0-4% hit, but can of course go higher. Intel has developed a workaround for the compilers that can, but not always, bring the performance back. Phoronix has tested this and even with recompilation Firefox is now slower:

Gaming is also affected and the chances of fixing it by recompilation are slim:

Sources:
https://www.phoronix.com/scan.php?page=article&item=intel-jcc-microcode
https://www.phoronix.com/scan.php?page=article&item=intel-jcc-gaming

 

[mtcn77]

Thanks, updated.

They can't fix it. Intel needs a new TLB protocol.
PS: so good to be back - first post since ban lift.

Zombieload v2 is kind of a curious case. When Zombieload was announced/revealed researchers did say Cascade Lake and co were also affected and pointed at TSX at enabling that. Intel vehemently denied this which was expected but there was little revealed in way of details. Apparently, now that Intel got some type of mitigation the time for details is here.

I start thinking this is Intel's marketing HR playbook. 'NetCat'? - such a coy way to describe an intruder...

Who comes up with these mainstream gaming nomenclature.

 

[InVasMani]

Intel inside now with 4% of the performance you paid for.

 

[KarymidoN]

I'm pretty sure when tech sites are typing news everytime they type intel the next sugestion is vulnerability...

 

[eidairaman1]

When will intel learn?

 

[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?

 

[londiste]

When will intel learn?

They learn constantly. Keep in mind that any problem that is discovered needs about a year or year and a half to fix in hardware. Software/Firmware changes are mitigations/workarounds and come with clear performance hits.

By the way, is Ice lake affected by these issues?

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?

Both. The main Spectre issues do affect AMD mostly to a lesser degree.

Most research papers for these vulnerabilities have testing started from Ivy Bridge or Haswell. The parts of CPUs that vulnerabilities are discovered in have remained largely same for a long time. Vulnerabilities are not a single thing that is discovered. Intel CPUs have been picked apart in terms of how they work. The mechanics of TLB, caches etc have been researched and the knowledge is incrementally more detailed. Side-channel attack vectors and methods have been gradually improved and discovered/invented. Spectre was culmination of years of research. Most of newer vulnerabilities are Intel microarchitecture specific. A lot of this is new research directions that were opened by Spectre.

AMD's Zen is partially based on previous AMD CPUs but it is a new spin on things. Intel's last new spin on things type architecture was Core with Nehalem in 2010 (or perhaps Conroe back in 2006). Market share and CPUs that are out there also play a part. AMD's architecture is newer (less time to pick it apart in enough detail) and was less relevant in terms of market share.

This is not to say AMD is not secure. Zen definitely is more secure than Intel's Core at this point.

 

[mtcn77]

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?

Intel's TLB is bugged. It needs replacement, too bad current generations have not touched its inner workings.

 

[Vya Domus]

When will intel learn?

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. Only thing that's going to put all of this to rest would be a clean new design otherwise this will never end.

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?

I'd say AMD has been under the same spotlight for some time now and nothing major stood out yet.

 

[Steevo]

So Intel has had leaky architecture they allowed with huge security holes to get their performance crown. It's like finding someone cheated by taking steroids, or cheated in a car race, but with your private data.

Why don't they just come out and say, "we cut corners to make money, but if you don't mind the security we are still slightly faster at 720P gaming".

 

[gunbuster]

I look forward to forking over $600 for Intel 14NM+++++++++++ with extra software and BIOS mitigation's in 2020 That will just break even with 2018 pre meltdown performance.

 

[chaosmassive]

if you don't mind the security we are still slightly faster at 720P gaming

you can strolling around in r/intel thread, this is the most common excuse they will be using when giving build advice/guide

 

[Smartcom5]

Remember the best part, guys!
That very flaw Intel fixes (hopefully complete) now again is that very security flaw Intel said they got fixed/repaired already 6 months ago. Except that they didn't back then – but lied (sic!) about in doing so instead, despite they knew better. So if anyone may wonder who may have been come up with it, it was some university some people may remember now …

Yup, that is the very same Dutch Vrije Universiteit Amsterdam that Intel tried to bribe six month ago in offering money for de·lay·ing said informations for some additional six months (huge thanks @MAXLD for your quite insightful managing of putting together unknown pieces!). These very six months are up as of yesterday. It's just that we now know what exactly they tried to hide. The today's 77 new flaws.

So these $40K and $80K they tried them to swallow back then (after being legitimately paid the $100K bounty) were supposed to pay for the very silence the researchers were about to engage for another six months;

The Dutch researchers had remained quiet for eight months about the problems they had discovered while Intel worked on the fix it released in May. Then when Intel realized the patch didn’t fix everything and asked them to remain quiet six more months, it also requested that the researchers alter a paper they had planned to present at a security conference to remove any mention of the unpatched vulnerabilities, they said. The researchers said they reluctantly agreed to comply because they didn’t want the flaws to become public knowledge without a fix.
“We had to redact the paper to cover for them so the world would not see how vulnerable things are,” said Kaveh Razavi, also a professor of computer science at Vrije Universiteit Amsterdam and part of the group that reported the vulnerabilities. — Kim Zetter, editor New York Times · Intel Fixes a Security Flaw It Said Was Repaired 6 Months Ago

Makes one wonder when the next bunch is going to hit in we ain't aware of yet – but are kept secret for now.
Like the tight-lipped Bitdefender warning they issued in August. Today's new security-flaws seem to be mostly coming from that Dutch Vrije Universiteit Amsterdam in May.

Yeah, like many say since a while and like we all should know by now, the very day Meltdown & Spectre went public, Intel reflexively engaged into another (st)age of their infamous mode ›Cover-up‹. It seems to be some age of fraud actually.

I mean, if you consider how long they have had been informed about the issues back in the middle of 2017 well in advance before anyone else and how little they did. They kept shut about everything – and most likely they would've liked to keep everything under the rug. It's just that the Linux kernel-developer went public on January '18 as they got so darn fed up on how Intel handled all this that those leaked those anyway – after over half a year Intel did exactly no·thing, not even informing OEMs.

Funny enough, the Linux kernel-developer even vastly helped Intel to such an extent getting rid of those flaws without ANYONE noticing, that only a handful of kernel-developers (and only the most trusted ones) brought in given kernel-patches silently with·out ANY info on what exactly they were doing on it just around Christmas in 2017 (so when everyone is with their family and no-one would hopefully get notice of it) – which is a stark and the utmost extreme novum never happening before in the rather transparent open-source community. That being said, it escalated as Intel demanded more and more from them effectively doing their work hiding dirty laundry until it blew out publicly as even those few involved got just sick to the back teeth on how Intel was handling it.

It's actually ridiculous! Intel even failed to inform U.S. cyber security officials about the Meltdown's and Spectre's chip flaws ahead of when they leaked to the public even though Intel had advanced knowledge of the vulnerabilities! Let that just sink in for a minute or two… that not even U.S. authorities may have been aware of Meltdown and Spectre beforehand – but have been made so when those went public.

I really don't know what's going on at this company the last couple of years, but I firmly believe that a company's management which is honestly thinking they actually could get through with it when only trying to sweep all that under the table just hard enough and paying everyone involved to keeping their mouths shut about everything just long enough for being forgotten, can't be really driven by anything else than pure insanity. They surely have some mentality problem with their culture of concealment and their continuous obstructionism.

Nothing less than mindblowing already …

Oh, and just in case anyone wonders if there's more to come on this or why their stock-price doesn't really seem to be affected by any kind of those major flaws ever since;
That's just since they constantly backing up themselves by buying their own stocks en masse. For instance, last quarter they already bought up 107M shares being worth just about 5.6 billions (see page 6,11), according to their own numbers.

This recent quarter they just finished, they again bought back 209M shares and thus virtually twice as much over a worth of about +$10B (see page 10 on their official quarterly reports) – which adds up to roughly $15B on buybacks just on the last two quarters – and yet they just decided to even top that (as the board gave their green light) by spending even $20B on buybacks atop when their board just authorised an increased buyback-program over $20B (sic!) for repurchasing shares with given worth within the next 15-18 months (see p. 4 on link above). That's just about $35B spend on buybacks in such a short time-frame, which is just straight out insane! They literally just doubled the amount of money spend on buybacks each time as of now, just let that sink in for a while.

So they're actively using their own stock's sudden fall in prices after quarter-results going public to buy their own fallen stocks in large numbers. If that isn't already sketchy, I don't know what it is …

Then again, if we've learned something from the past, that's it, that if a company buys up their own shares in such a large amount, it mostly was a sure sign that something wasn't right at all with the company – and that the management often enough helplessly tried to hold up the masquerade as long as it's possible prior to end all this with a big, fundamental final bang. Do we have to be kinda worried here?

Good Lord, Intel. How you have fallen …

Smartcom

 

[R0H1T]

They'll continue doing this as long as they get away with it, me thinks a few more decades at the very least

 

[londiste]

So Intel has had leaky architecture they allowed with huge security holes to get their performance crown. It's like finding someone cheated by taking steroids, or cheated in a car race, but with your private data.

Where does this assumption come from that these vulnerabilities assist in performance? They don't.

 

[trparky]

Intel inside now with 4% of the performance you paid for.

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.

Where does this assumption come from that these vulnerabilities assist in performance? They don't.

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.

 

[londiste]

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.

Anything that is done in software or firmware/microcode is inevitably expensive in terms of performance. Simply put, mitigations are using software ways to actively avoid certain vulnerable states.

In Cascade Lake there are hardware mitigations in place for Meltdown/L1TF/MDS and some assisting changes for Spectre V2 and SSB. As a result, software mitigations for these are turned off and there is no performance loss. Phoronix's mitigation performance hit testing for Cascade Lake showed performance hit for Intel CPUs to be in the same 4-6% range as AMD CPUs. Some performance decrease is still there because Spectre V1/V2 and SSB have mitigations in place across the board.

Of course, when a new vulnerability is discovered, there will be new mitigations and new performance hit. Fixing one of these vulnerabilities in hardware takes about year or year and a half. Not because the fix is that complex but in addition to doing the actual fix it needs to fit into CPU manufacturing cycle. By the way, this is an area where Intel has screwed up pretty bad because hardware changes are not in sync with CPU SKU-s. Intel's table about mitigations and fixes - for example you can get an i5-9400 with Stepping 11, 12 or 13 all of which have different level of hardware fixes in place.

 

[er557]

TSX has been awall since early microcode on haswell-ep, so I presume no issue in my system.