SWAPGS is a new vulnerability in the CPU speculative execution mechanism

Researchers at Bitdefender have revealed new vulnerability (CVE-2019-1125) in the speculative instruction execution mechanism of modern CPUs, which received the name SWAPGS, corresponding to the name of the processor instruction causing the problem. Vulnerability Allows to an unprivileged attacker to determine the contents of kernel memory areas or running virtual machines. Problem confirmed by in Intel processors (x86_64) and partially affects AMD processors for which the main attack vector does not appear. Previously implemented Specter and Meltdown mitigations do not protect against the SWAPGS attack on Intel processors, but fixes have already been proposed for Linux, ChromeOS, Android, and Windows.

The vulnerability belongs to the Specter v1 class and is based on the idea of ​​restoring data from the processor cache left after the speculative execution of instructions. The branch prediction blocks of modern CPUs, in order to improve performance, preemptively execute some instructions that are most likely to be executed, but without waiting for the calculation of all the factors that determine their execution (for example, when branch conditions or access parameters have not yet been calculated). If the prediction is not confirmed, the processor discards the result of the speculative execution, but the data processed during it settles in the processor cache and can be restored using methods for determining the contents of the cache through third-party channels that analyze the change in the access time to cached and not cached data.

A feature of the new attack is the use of a leak that occurs during the speculative execution of the SWAPGS instruction, which is used in operating systems to replace the value of the GS register when control passes from user space to the OS kernel (the GS value used in user space is replaced by the value used during operations in the kernel ). In the Linux kernel, GS stores the per_cpu pointer used to access kernel data, and in user space, pointers to TLS (Thread Local Storage).

To prevent the SWAPGS instruction from being called twice when the kernel is accessed again from kernel space or when code is executed that does not require the GS register to be replaced, a check and a conditional branch are performed before the instruction. The speculative execution mechanism advances to executing the code with the SWAPGS instruction without waiting for the result of the check, and if the selected branch is not confirmed, it discards the result. Thus, a situation may arise when a branch that does not involve SWAPGS execution is speculatively chosen, but during the speculative execution, the value of the GS register will be changed by the SWAPGS instruction and used in dependent memory operations that settle in the CPU cache.

The researchers proposed two attack scenarios for which exploit prototypes were prepared. The first scenario is based on the situation where the SWAPGS instruction is not speculatively executed, although it is used in actual execution, and the second is the opposite, when the SWAPGS instruction is speculatively executed, although it should not actually be. There are two exploits for each scenario: an attacker can determine a value at a specific address in the kernel area, and an attacker can search for a specific value at random addresses in the kernel. An attack takes a long time to complete, and a leak may require an exploit to run for several hours.

Problem in Linux kernel eliminated by changing the logic of calling the SWAPGS instruction (blocking speculative execution), by analogy with fixing other vulnerabilities of the Specter v1 class. The added security is expected to have minimal performance impact on typical workloads. Latency occurs during the switching phase between user space and kernel space, which can lead to performance degradation, for example, if the application makes heavy system calls or generates frequent NMIs and interrupts.

The fix requires installing a kernel update in both the host system and the guest environments, followed by a system reboot. To disable protection on Linux, the "nospectre_v1" option can be used, which also disables measures to block the SWAPGS vulnerability. The fix is ​​available as patch for a Linux kernel that is already included in releases 4.19.65, 5.2.7, 4.14.137, 4.9.188 and 4.4.188. Updates for Linux distributions have not yet been released (Debian, RHEL, Fedora, Arch Linux, SUSE/openSUSE, Ubuntu). On Windows, the problem has been discreetly fixed in July update. Google has prepared fix for kernel 4.19 shipped with ChromeOS and Android.

According to researchers at Bitdefender, Intel was aware of the problem as early as August last year. It was decided to fix the problem programmatically, for which developers from Microsoft, Google and the Linux kernel were involved in the coordinated development of the fix. Older Intel processors, before Ivy Bridge, are much more difficult to attack due to the lack of support for the WRGSBASE instruction used in the exploit. ARM, POWER, SPARC, MIPS, and RISC-V systems are not affected because they do not support the SWAPGS instruction.

The problem threatens mainly the owners of Intel processors -
on AMD systems, only the second attack scenario was able to be reproduced, which was limited to speculative processing of the base value of the GS register, which can be used to search for certain values ​​in random areas of memory. To block this attack enough existing methods of protection against vulnerabilities Specter v1.

Source: opennet.ru

Add a comment