After vulnerabilities like Spectre and Meltdown were discovered in 2018, Intel processors have more vulnerabilities with the Downfall attacks that target the Gather instruction part of AVX2/AVX-512 and impact 6th generation Skylake up to 11th generation Tiger Lake processors introduced as far back as 2014.
It does not affect more recent processors, and as somebody who has just purchased a laptop based on a 13th Raptor Lake processor, I guess I can breathe a sigh of relief until the next vulnerability is discovered, but people using hardware with older Intel processors will have to update the OS and suffer from a performance impact, at least for tasks leveraging AVX2 or AVX-512.
The website about the Downfall vulnerability explains:
Downfall attacks targets a critical weakness found in billions of modern processors used in personal and cloud computers. This vulnerability, identified as CVE-2022-40982, enables a user to access and steal data from other users who share the same computer. For instance, a malicious app obtained from an app store could use the Downfall attack to steal sensitive information like passwords, encryption keys, and private data such as banking details, personal emails, and messages. Similarly, 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.
The vulnerability is caused by memory optimization features in Intel processors that unintentionally reveal internal hardware registers to software. 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. To exploit this vulnerability, I introduced Gather Data Sampling (GDS) and Gather Value Injection (GVI) techniques.
Intel Processor Advisory INTEL-SA-00828 rates it as medium severity and describes it as:
Information exposure through microarchitectural state after transient execution in certain vector execution units for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
The company also issued a statement to various news sources about the vulnerability which was discovered in :
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 Linux 6.5 kernel has a patch to “Mitigate Gather Data Sampling issue” and Intel has released a microcode update for the Downfall vulnerability also known as “Gather Data Sampling” (GDS). Note this was reported in August 2022 (yes, that’s one year ago) and it took a long while before the issue was “fixed”. While Intel says the mitigation may be disabled, considering the performance impact of up to 50% allegedly communicated to partners, the downfall website says it might not be such a good idea:
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.
AVX-512 and AVX2 SIMD instructions are often used for multimedia (audio/video) decoding and encoding, so I’d expect many people to be impacted, and applying any mitigations for your preferred OS should be an important thing to do even if it impacts performance to some extent. I understand the 50% performance hit is a worse-case scenario, so we’d have to see how it pans out for typical workloads that leverage the GATHER instruction.
Via Phoronix.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Did I miss it or did you also cover AMD’s most recent (and rather similar) known CPU vulnerabilities called Zenbleed and Inception?
It’s the first time I read about those.
I noticed as well (and I know it’s not the case here), that there tends to be some fanboyism among some groups who will say “ah yes there’s a harmless bug on AMD” then “oh look, yet another issue on intel, what a pile of crap”! It could have been the case on slashdot a decade ago for example.
As long as it is not exploitable from code running in web browsers, I do not think that this is as important for personal computers. A malicious app running natively has many attack vectors anyways.
I agree. Such vulnerabilities are only a problem for virtualization and cloud vendors (and users). As long as there will be people who believe that tasks running on the same hardware, competing for the same caches and busses, will run unaffected by the activity of the other one, there will be such issues. The reality is that any other task’s activity can be detected. And the level of detection can sometimes go as low as to very precisely infer the other task’s activity by exploiting the various mechanisms that are in place to permit such tasks to coexist with a… Read more »
> Such vulnerabilities are only a problem for virtualization and cloud vendors (and users).
The downfall website states ‘a malicious app obtained from an app store could use the Downfall attack to steal sensitive information like passwords, encryption keys…’
That’s step 1 in a ‘privileges escalation’ scenario and since keys are involved also probably a ‘taking over the whole network’ scenario.
apps from app stores are a good example of totally untrustable programs that must absolutely be run in isolation (emulation, syscall wrappers etc). Regardless, what can be stolen by such attacks is totally non-deterministic, so the worst case is evocated but in practice you get tons of garbage and from time to time something that you can interpret. Lawyers and mass-media insist on encryption keys and passwords. But farming millions of machines like this with applications hoping to collect 0.001% of successful data with 50% of noise is probably not as profitable as spending time developing dummy banking web sites.
Quoting the Zenbleed page:
“It turns out that mispredicting on purpose is difficult to optimize! It took a bit of work, but I found a variant that can leak about 30 kb per core, per second.
This is fast enough to monitor encryption keys and passwords as users login!”
No app store needed, this works as any unprivileged user on any affected system.
Yes, exactly what I mentioned above: strong isolation on a shared local system is an illusion and a wrong paradigm from the beginning, and only an issue in environments where contexts are shared. The practical reality is that the vast majority of us use private systems that are not shared with other people. I mean, count the number of non-system accounts on your laptop. Most likely there’s a single one, yours, like many of us. And this vast majority of users constantly have to endure performance regressions that are required to protect shared systems.