The vulnerability is due to memory optimization features in Intel processors.
Newly, a vulnerability has been discovered in the speculative instruction execution system of Intel processors, and this time a Google researcher, announced that he identified a new vulnerability (already cataloged under CVE-2022-40982), called «Downfall»
Downfall, is a vulnerability that allows determining the content of the XMM, YMM and ZMM vector registers, previously used by other processes when executing AVX instructions on the same CPU core.
About Downfall
Regarding vulnerability, it is mentioned that an unprivileged attacker with the ability to run your own code on the system, could use the vulnerability to leak data from other user processes, the system kernel, isolated Intel SGX enclaves, and virtual machines.
Filterable vector registers are widely used in encryption, memory copy functions, and string processing, for example, these registers are used in the Glibc library in the memcpy, strcmp, and strlen functions, among other things. From a practical point of view, the vulnerability could be exploited to determine the data being processed in AES-NI or REP-MOVS instructions (used in the memcpy function) in other processes, which could leak encryption keys, sensitive data and user passwords.
Vulnerability manifests itself in Intel processors which support AVX2 and AVX-512 extended instruction sets (meaning it affects 6th to 11th generation processors), while Intel processors based on the Alder Lake, Raptor Lake and Sapphire Rapids microarchitectures do not they seem affected.
As with the recently discovered Zenbleed vulnerability affecting AMD Zen2 processors, in Downfall, the reason for the vulnerability is data leakage from log files, which are used to share log content across all applications. tasks on the same CPU core.
The leak is due to a speculative data transfer when executing the GATHER statement, available in AVX2 and AVX-512 extensions, and designed to provide fast access to disparate data in memory. During the execution of the GATHER statement, the old data in the register file is used in the speculative execution of dependent instructions. This data is not directly reflected in software logs, but can be determined using side-channel attack techniques designed for Meltdown attacks, such as parsing leftover data in the CPU cache.
To exploit Downfall, an attack technique was developed called Gather Data Sampling (GDS) and for which exploit prototypes have been published to extract cryptographic keys from another user's process, leak data after it was copied into the Linux kernel by the memcpy function, and intercept printed characters left in vector registers after other processes work. For example, it demonstrates the ability to define AES keys that are used to encrypt data in another user's process using the OpenSSL library.
The method showed high efficiency: by conducting an experiment with 100 different keys, 100% of AES-128 keys and 86% of AES-256 keys were determined with the duration of each attempt to determine no more than 10 seconds. In cloud systems, an attack can be used to determine what data is being processed in other virtual machines. It is possible that the vulnerability could be exploited by executing JavaScript code in a web browser.
It should be mentioned that Intel found out about the problem last year (precisely in the month of August) and that the vulnerability was only made public this year at the BlackHat USA conference. and fixes to guard against the vulnerability are already included in the various Linux kernel updates ranging from version 6.4.9 6.1.44 to 4.14.321.
In addition to this, among the possible measures to avoid the negative impact of the protection against the Downfall vulnerability on performance, it is mentioned making changes in the compilers to disable the use of the GATHER statement or adding the statement immediately after the GATHER LFENCE, which disables preemptive execution of subsequent statements before all previous commits have completed.
For systems where firmware fixes are not available, support for all AVX extensions has been disabled, while for the Intel microcode update part, it also provides the ability to use the MSR interface to selectively disable the firmware. protection in the context of individual processes.
Finally, if you are interested in knowing more about it, you can check the details in the following link