Intel 'Downfall' Bug Steals Encryption Keys, Data From Years of CPUs (Update)

Sapphire Rapids
(Image credit: ServeTheHome Forums)

A new security vulnerability, called Downfall, was revealed today by Intel and the researcher who discovered it, Daniel Moghimi. The new attack uses Gather Data Sampling to steal data and other sensitive information from other users on a computer with Intel processors from 2015 through 2019 ranging from sixth gen Skylake through eleventh gen Rocket Lake and Tiger Lake.

Intel has posted about the vulnerability in a security advisory, INTEL-SA-00828, and has reserved CVE-2022-40982.

Moghami, a senior research scientist at Google (and formerly of the University of California San Diego posted details on downfall.page.

"The vulnerability is caused by memory optimization features in Intel processors that unintentionally reveal internal hardware registers to software," Moghami wrote. "This allows untrusted software to access data stored by other programs, which should not be normally be accessible. I discovered that the Gather instruction, meant to speed up accessing scattered data in memory, leaks the content of the internal vector register file during speculative execution."

On the page, Moghami shows demos stealing 128-bit and 256-bit AES keys from other users, as well as spying on typed characters and taking data from the Linux kernel. He suggests that even if you don't own an Intel powered-device, Intel's dominance in the server market means that everyone on the internet is affected, and that "in cloud computing environments, a malicious customer could exploit the Downfall vulnerability to steal data and credentials from other customers who share the same cloud computer."

Intel is releasing microcode for its affected chips. The company "recommends that users of affected Intel Processors update to the latest version firmware provided by the system manufacturer that addresses these issues." If you're not using Intel SGX, a hardware-based memory encryption technology from Intel, you can load it from the operating system.

In a statement to Tom's Hardware, Intel wrote: "The security researcher, working within the controlled conditions of a research environment, demonstrated the GDS issue which relies on software using Gather instructions. While this attack would be very complex to pull off outside of such controlled conditions, affected platforms have an available mitigation via a microcode update. Recent Intel processors, including Alder Lake, Raptor Lake and Sapphire Rapids, are not affected. Many customers, after reviewing Intel's risk assessment guidance, may determine to disable the mitigation via switches made available through Windows and Linux operating systems as well as VMMs. In public cloud environments, customers should check with their provider on the feasibility of these switches.”

The overhead, per Moghami and Intel, could be as high as 50% depending on if a workload uses Gather. Notably, Intel will have an "opt-out mechanism" in the microcode that allows the mitigation for Downfall to be disabled in order to "avoid the performance impact on certain vectorization-heavy workloads."

The researcher recommends against opting out: "This is a bad idea. Even if your workload does not use vector instructions, modern CPUs rely on vector registers to optimize common operations, such as copying memory and switching register content, which leaks data to untrusted code exploiting Gather."

Moghami will present Downfall at the BlackHat USA conference on August 9 and USENIX Security Symposium on August 11. His technical paper can be found here.

Newer Intel chips, like 12th Gen Alder Lake, 13th Gen Raptor Lake, and Sapphire Rapids server chips aren't affected. 

Updated August 9 with comment from Intel.

Andrew E. Freedman is a senior editor at Tom's Hardware focusing on laptops, desktops and gaming. He also keeps up with the latest news. A lover of all things gaming and tech, his previous work has shown up in Tom's Guide, Laptop Mag, Kotaku, PCMag and Complex, among others. Follow him on Threads @FreedmanAE and Mastodon @FreedmanAE.mastodon.social.

  • hotaru251
    holy crap potential impact of 50%? thats a crazy high impact.
    Reply
  • bit_user
    hotaru251 said:
    holy crap potential impact of 50%? thats a crazy high impact.
    Only for AVX2/AVX-512 workloads, I think. And ones which use the Gather instruction, at that.

    I'm going to reserve judgement until detailed benchmarks are in. Phoronix is running them now.
    Reply
  • spoidz
    you can load it from the operating system.

    I hope that means we won't have to hope for very old Motherboard support to provide them, my Z390 Dark is well past support.
    Reply
  • bit_user
    spoidz said:
    I hope that means we won't have to hope for very old Motherboard support to provide them, my Z390 Dark is well past support.
    Operating systems usually apply the latest microcode during boot-up. Of course, that assumes you're regularly installing your security patches (Windows Updates, etc.).
    Reply
  • rluker5
    bit_user said:
    Operating systems usually apply the latest microcode during boot-up. Of course, that assumes you're regularly installing your security patches (Windows Updates, etc.).
    Hopefully this is the case. It will help all of those who update then.
    And I hope this story is big enough that most people that manage servers get it.

    Not good news for Intel server chips. Ice lake is pretty recent.
    Reply
  • bit_user
    rluker5 said:
    Not good news for Intel server chips. Ice lake is pretty recent.
    Agreed, but mostly for workloads like AI, software video codecs, HPC, etc. That's a minority of what's running on those CPUs, I'd bet.
    Reply
  • Findecanor
    bit_user said:
    Only for AVX2/AVX-512 workloads, I think. And ones which use the Gather instruction, at that.
    It's the opposite. The Gather-instruction is used for the exploit, because it is the circuitry for that instruction that has the bug.

    Any data that is ever loaded into vector registers could potentially leak. And vectors are used not just for parallelised operations but also for floating point maths, encryption, bulk memory copy and context switches.
    Reply
  • bit_user
    Findecanor said:
    It's the opposite. The Gather-instruction is used for the exploit, because it is the circuitry for that instruction that has the bug.
    I was talking about what the microcode fix targets. Maybe you know more about it than I do, but I assumed that since the gather instructions were used in the exploit, that the microcode fix (and therefore its performance impact) would affect primarily that instruction. I'm still waiting to see detailed benchmarks, so we can get more insight.

    Findecanor said:
    Any data that is ever loaded into vector registers could potentially leak. And vectors are used not just for parallelised operations but also for floating point maths, encryption, bulk memory copy and context switches.
    Floating point and encryption, yes. You can't really get around that, because ever since SSE came onto the scene, x87 math has received very little focus or attention from CPU designers. So, even for scalar arithmetic, you're still probably using the vector registers.

    Memory copy is an easy one to disable. That's mainly libc, and it still has a fallback path for using non-vector copies.

    Context switches? Aside from the mere fact of saving vector registers as part of the context, why? Is it again something that's done as an optimized memory copy?

    For me, a key question is whether information-leakage happens across context switches (i.e. with SMT disabled). That would mean that simply disabling or limiting SMT would be an incomplete mitigation of this exploit.
    Reply
  • rluker5
    Findecanor said:
    It's the opposite. The Gather-instruction is used for the exploit, because it is the circuitry for that instruction that has the bug.

    Any data that is ever loaded into vector registers could potentially leak. And vectors are used not just for parallelised operations but also for floating point maths, encryption, bulk memory copy and context switches.
    But this exploit only exists with the use of Gather data sampling. Is there another way to read the data of other users on a shared system? The article does specifically state that gather is responsible for leaking the data.

    There is lots of data sitting in places in a CPU. Unless it is read and made leakable it is safe. I'm reading that Gather is a low level instruction set authorized to do this. You can't just use file explorer to read vector registers.
    Reply
  • RichardtST
    No surprise, really. System complexity has gone through the roof in the last decade or so and it has become impossible to make anything secure. It is a well-known fact that security is a losing battle at this point. Good news is that CPUs are cheap enough that no one should be sharing them. If you have something that is actually important then dedicate a machine to it. And for heaven's sake get it off the cloud. We've only been warning of things like this for years. Now it is officially here. One more thing.... "I told you so".
    Reply