The project recently Grsecurity made known through a publication details and a demo an attack method for a new vulnerability (already listed as CVE-2021-26341) on AMD processors related to the execution of speculative instructions after unconditional jump-forward operations.
Vulnerability allows the processor to speculatively process the instruction immediately after the jump (SLS) instruction in memory during speculative execution. At the same time, such optimization works not only for conditional jump operators, but also for instructions that involve a direct unconditional jump, such as JMP, RET, and CALL.
Unconditional branch instructions can be followed by arbitrary data that is not intended for execution. After determining that the branch does not involve execution of the next statement, the processor simply rolls back the state and ignores speculative execution, but the instruction execution trace remains in the general cache and is available for analysis using side-channel retrieval methods.
AMD provides an update for a recommended mitigation, the G-5 mitigation, in the "Software Techniques for Managing Speculation in AMD Processors" whitepaper. The G-5 mitigation helps address potential vulnerabilities associated with speculative behavior of branch instructions.
AMD processors may transiently execute instructions following an unconditional forward branch which may result in cache activity
As with the exploitation of the Spectre-v1, an attack requires the presence of certain sequences of instructions (gadgets) in the kernel, which leads to speculative execution.
In this case, blocking a vulnerability boils down to identifying such devices in the code and adding additional instructions to them that block speculative execution. Conditions for speculative execution can also be created using non-privileged programs running on the eBPF virtual machine.
This investigation resulted in the discovery of a new vulnerability, CVE-2021-26341 [1] , which we will discuss in detail in this article. As usual, we will focus on the technical aspects of the vulnerability, the mitigations suggested by AMD, and the exploitation aspects.
To block the ability to build devices using eBPF, it is recommended to disable unprivileged access to eBPF in the system ("sysctl -w kernel.unprivileged_bpf_disabled=1").
The vulnerability affects processors based on the Zen1 and Zen2 microarchitecture:
Desktop
- AMD Athlon™ X4 processor
- AMD Ryzen™ Threadripper™ PRO Processor
- XNUMXnd Generation AMD Ryzen™ Threadripper™ Processors
- XNUMXrd Generation AMD Ryzen™ Threadripper™ Processors
- XNUMXth Generation AMD A-series APU
- AMD Ryzen™ 2000 Series Desktop Processors
- AMD Ryzen™ 3000 Series Desktop Processors
- AMD Ryzen™ 4000 Series Desktop Processors with Radeon™ Graphics
Mobile
- AMD Ryzen™ 2000 Series Mobile Processor
- AMD Athlon™ 3000 Series Mobile Processors with Radeon™ Graphics
- AMD Ryzen™ 3000 Series Mobile Processors or XNUMXnd Generation AMD Ryzen™ Mobile Processors with Radeon™ Graphics
- AMD Ryzen™ 4000 Series Mobile Processors with Radeon™ Graphics
- AMD Ryzen™ 5000 Series Mobile Processors with Radeon™ Graphics
Chromebook
- AMD Athlon™ Mobile Processors with Radeon™ Graphics
employee
- First Generation AMD EPYC™ Processors
- XNUMXnd Generation AMD EPYC™ Processors
It is mentioned that if the attack is successful, the vulnerability allows the content of arbitrary memory areas to be determined.
Due to this vulnerability, it may be possible to identify benign code constructs that form limited but potentially exploitable SLS devices on affected CPUs. As demonstrated with the eBPF example, it is also possible to exploit the vulnerability with hand-built, self-injected devices. The presented method can be used, for example, to break the KASLR mitigation of the Linux kernel.
For example, researchers have prepared an exploit that allows you to determine the layout of the address and bypass the KASLR (kernel memory randomization) protection mechanism by executing code without privileges in the eBPF kernel subsystem, in addition to Other attack scenarios that could leak the contents of kernel memory are not ruled out.
Finally if you are interested in knowing a little more about it, you can check the details In the following link.