A team of researchers from the Technical University of Dresden has identified a vulnerability (CVE-2020-12965) in AMD processors based on Zen+ and Zen 2 microarchitectures that allows a Meltdown class attack. Initially, AMD Zen+ and Zen 2 processors were not expected to be affected by the Meltdown vulnerability, but researchers have identified a feature that leads to speculative access to protected memory areas when using non-canonical virtual addresses.
The AMD64 architecture only uses the first 48 bits of the virtual address and ignores the remaining 16 bits. It is specified that bits 48 to 63 must always copy the value of bit 47 (sign bit extension). If this condition is violated and an attempt is made to access the address with arbitrary values of the upper bits, the processor generates an exception. The repeated filling of the upper bits leads to the division of the available address space into two blocks - the lower one (from 0 to 00007FFFFFFFFFFF), in which the upper bits are set to zero, and the upper one (from FFFF800000000000 to FFFFFFFFFFFFFFFF), in which all the upper bits are set to 1.
Addresses falling under the specified blocks are called canonical, and incorrect addresses with arbitrary contents of the upper bits are called non-canonical. The lower range of canonical addresses is usually allocated for process data, while the upper range is used for kernel data (access to specified addresses from user space is blocked at the privilege sharing level).
The classic Meltdown vulnerability is based on the fact that during the speculative execution of instructions, the processor can access a private data area, and then discard the result, since the set privileges prohibit such access from the user process. In a program, a speculatively executed block is separated from the main code by a conditional jump, which in real conditions always fires, but due to the fact that the conditional statement uses a calculated value that the processor does not know during pre-emptive code execution, all branching options are speculatively executed.
Since the same cache is used for speculatively executed operations as for normally executed instructions, it is possible during speculative execution to set markers in the cache that reflect the contents of individual bits in a private memory area, and then in normally executing code determine their value through time analysis. accessing cached and non-cached data.
A feature of the new vulnerability that affects AMD Zen + and Zen 2 processors is that CPUs allow speculative read and write operations that access memory using invalid non-canonical addresses, simply ignoring the upper 16 bits. Thus, in the process of speculative code execution, the processor always uses only the lower 48 bits, and the address validity check is performed separately. If, when translating a non-canonical virtual address into a physical address in the TLB, a match is found in the canonical part of the address, the speculative load operation will return a value without taking into account the contents of the upper 16 bits, which avoids memory sharing between threads. Subsequently, the operation will be invalidated and discarded, but the memory access will be performed and the data will settle in the cache.
During the experiment, using the technique of determining the contents of the cache FLUSH + RELOAD, the researchers managed to organize a channel for covert data transfer at a speed of 125 bytes per second. In addition to AMD chips, the problem also affects all Intel processors affected by the classic Meltdown vulnerability. The same techniques that help block Meltdown attacks, such as using LFENCE instructions, can be used to protect against the new kind of attack. For example, if the Intel processor includes hardware protection against Meltdown, or software protection is enabled in the system, then such configurations are not subject to a new attack variant.
At the same time, the researchers note that, compared to Intel processors, the architecture of AMD processors limits the possibility of real attacks, but does not exclude the use of a new method in combination with other microarchitectural attacks to increase their effectiveness. In particular, the proposed attack variant does not allow one to determine the contents of the kernel memory areas and other processes, but is limited to the ability to gain access to other threads of the same program executing in the same virtual memory space.
Since a program without a vulnerability has the ability to access its own threads, from a practical point of view, the method is of interest for bypassing sandbox isolation and interfering with the work of other threads in programs that allow third-party code to be executed, such as web browsers and JIT engines. . The researchers studied the susceptibility of the SpiderMonkey JavaScript engine and the Linux kernel to the attack, but did not find vulnerable code sequences that could be used to carry out the attack. In addition to attacking applications, the method can also be used to force illegal data flows between microarchitectural elements of the processor while exploiting other microarchitectural vulnerabilities.
Source: opennet.ru