You are here

You are here

ZombieLoad is back: Intel kept new bug secret for 6 months

Richi Jennings Industry analyst and editor, RJAssociates

Intel is under fire this week, for allegedly misusing responsible-disclosure norms. Some of the researchers behind the ZombieLoad flaw, disclosed back in May 2019, say Intel forced them to downplay the seriousness of what they found.

Not only that, said researchers say, but Intel did a poor job of patching the bug. Here comes another microcode update—and this time, the group isn’t keeping quiet about it.

It’s a complex problem, though. In this week’s Security Blogwatch, we wonder if it’s even fixable.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: centerline.

RIDL me this

What’s the craic? Shaun Nichols has déjà vu—True to its name, Intel CPU flaw ZombieLoad comes shuffling back with new variant:

Intel is once again moving to patch its CPU microcode following the revelation of yet another data-leaking side-channel vulnerability. The same group of university boffins who helped uncover … Spectre and Meltdown [say] a third issue, reported back in May under the name ZombieLoad, extends even further … than previously thought.

When the bug was publicly disclosed earlier this year, Intel said its latest chips – its 8th and 9th generation Core and second-generation Xeon Scalable microprocessors – were not vulnerable to this so-called Microarchitectural Data Sampling (MDS) info leak. That, the researchers say, is [not] the case … even on Meltdown and Foreshadow-resistant silicon.

As it turns out, this issue has been known to both the manufacturer and the eggheads for some time, though was kept secret … so as to give [Intel] time to develop and release a fix. … Meanwhile, Chipzilla acknowledges this release does not fully remedy the problem.

It should be noted at this point that, while ZombieLoad and other side-channel attacks make for a good story, are fascinating to study, and do pose a hard-to-remove security vulnerability, they are … notoriously difficult to reliably exploit … and require the attacker to have already achieved arbitrary code execution on the target machine. … Meanwhile, large businesses are routinely getting ransacked via spear-phishing emails and poisoned Office documents.

And Andy Greenberg piles on—Intel Failed to Fix a Hackable Chip Flaw Despite a Year of Warnings:

Researchers at Vrije Universiteit … KU Leuven, [the] Helmholtz Center for Information Security, and the Graz University of Technology … revealed new versions of a hacking technique … in Intel chips. They're spins on something known as ZombieLoad or RIDL, an acronym for Rogue In-Flight Data Load; Intel refers to it instead as … MDS.

[But] the researchers are pointing to a more serious failing on Intel's part than just another bug. While they warned Intel … as early as September 2018, [it] has nonetheless neglected to fix the flaws in the nearly 14 months since. … The company itself admits that [this week’s] fixes still don't fully protect against the MDS attacks.

[An] attack could include anything from a website's Javascript running in a victim's browser to … a virtual machine on the same … cloud server. [It could] steal sensitive data from other parts of the computer that [attackers] shouldn't have access to … like cryptographic keys or passwords.

VUSec researchers say … they've managed to hone it into a technique capable of stealing sensitive data in seconds rather than the hours or days they previously believed necessary.

The VUSec team also warned Intel in May that its fix at the time was incomplete. [It] represents a serious oversight by Intel.

What do the researchers have to say for themselves? Cristiano Giuffrida, Kaveh Razavi, and Herbert Bos seem to say Intel is incompetent—or worse (via Kim Zetter):

[In May, Intel said] everything is fixed [but] we knew that was not accurate. … We had to redact the paper to cover for them so the world would not see how vulnerable things are.

We think it’s time to simply tell the world that even now Intel hasn’t fixed the problem. … And they don’t intend to do proper security engineering until their reputation is at stake. … There are tons of vulnerabilities still left.

Many of the attacks they missed were a few lines of code different from the others. … The implication of this is of course worrisome. It means until we give them all possible variations of the problem, they won’t actually fix the problem.

More and more people knew about this vulnerability to the point that it actually circled back to us. So they provide an illusion that they have this whole disclosure process under control. But it’s not controlled at all; it’s leaking.

Anybody can weaponize this. And it’s worse if you don’t actually go public, because there will be people who can use this against users who are not actually protected.

And Intel itself? Jerry Bryant discusses the November 2019 Intel Platform Update:

Like many others in the industry, Intel is releasing security advisories as part of a regular monthly cadence. … We believe that assigning CVE ID’s and publicly documenting … vulnerabilities helps our customers to accurately assess risk, prioritize, and deploy updates.

CVE-2019-11135 is closely related to … MDS that we addressed in May of this year. Transactional Synchronization Extensions (TSX) Asynchronous Abort, or TAA, has a medium CVSS score of 6.5. [It] affects only CPU’s that support TSX. The TAA mitigation provides the ability to clear stale data from microarchitectural structures through use of a VERW instruction. … It also provides system software the means to disable TSX.

We believe that the mitigations for TAA and MDS substantively reduce the potential attack surface. Shortly before this disclosure, however, we confirmed the possibility that some amount of data could still be inferred through a side-channel using these techniques.

Yet another microcode briar-patch? DoMiNeLa10 wonders what’s next:

I guess the joke about Intel CPUs losing performance on a monthly basis is as true as ever. Who knows how many of these are under embargo right now?

It sure looks bad for Intel. arglebargle_xiv says the company has form:

This is like Intel's ingenious 320-series self-bricking SSDs from a couple of years ago:

"We've fixed the bug that causes the drives to brick themselves."

"OK, now we've really fixed the bug that causes the drives to brick themselves."

"This time we've really really really fixed the bug that causes the drives to brick themselves, promise and pinky-swear."

"We've now resolved the problem by withdrawing the 320 from sale. … 320? What's that? We never sold anything like that, and it certainly never turned itself into an 8MB SSD when powered on. Nope, definitely never been an Intel product."

And Claptrap314 feels vindicated:

As I said when Spectre first come out—there is no fix without a very heavy penalty in performance/watt.

But what else could Intel do? L_A_G has a horrible thought:

Considering so many of these bugs are shortcuts made in the implementation of things like speculative execution, SMT and TLB that are invisible to the user and programmer that I don't think a machine without them would be unable to run the code. An x86 CPU without these things would essentially be a multicore 486 with modern vector instructions implementing the AMD64 instruction set, so not the fastest thing around, but not completely unworkable either.

Come to think of it, that wouldn't be that far off from Intel's Xeon Phi accelerator cards. So they could just dust off those things and do what they did in the early 2000s when they threw out the Pentium/Netburst lineage and promoted their mobile CPU lineage to their main desktop lineage.

Something must be done! Lindsey Barrett—@LAM_Barrett—suggests, errm, something:

The reason we need more substantive and meaningful privacy laws than “companies, please do not lie about the computers” is because it appears to be literally impossible for them to not do that.

Meanwhile, Zack Whittaker recycles an old Simpsons trope:

Time to reset your “days since last major chip vulnerability” counter back to zero.

The moral of the story?

Be on your guard, especially if your workloads share a physical server with other tenants’ code.

And finally

The surprising history of road markings

Previously in “And finally”

You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or Ask your doctor before reading. Your mileage may vary. E&OE.

Image source: Tamekia Andress (cc:0)

Keep learning