Researchers from Bitdefender discovered a new vulnerability () in the speculative execution mechanism of modern CPUs, named SWAPGS, corresponding to the processor instruction that causes the issue. The vulnerability allows an unprivileged attacker to determine the contents of kernel memory areas or running virtual machines. The issue in Intel processors (x86_64) and partially in AMD processors, for which the primary attack vector is not manifested. Previously implemented mitigations for the Spectre and Meltdown vulnerabilities do not protect against SWAPGS attacks on Intel processors, but fixes have already been proposed for Linux, ChromeOS, Android, and Windows.
The vulnerability belongs to the Spectre v1 class and is based on the idea of recovering data from the CPU cache that remains after speculative execution of instructions. Modern CPU branch prediction blocks enhance performance by using speculative execution of certain instructions that are most likely to be executed, without waiting for the calculation of all factors determining their execution (for example, when the branch conditions or access parameters have not yet been computed). If the prediction is not confirmed, the CPU discards the result of speculative execution, but the data processed in the course of it remains in the CPU cache and can be recovered using cache content determination methods through side channels that analyze the change in access time to cached and uncached data.
The feature of the new attack lies in the leakage 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 transitions from user space to kernel space (the user space value of GS is replaced with the value used during kernel operations). In the Linux kernel, GS holds a per_cpu pointer, used to access kernel data, while in user space, it points to TLS (Thread Local Storage).
To prevent the double invocation of the SWAPGS instruction when repeatedly accessing the kernel from the kernel space or when executing code that does not require the replacement of the GS register, a check and conditional jump are performed before the instruction. The speculative execution mechanism preemptively switches to execute the code with the SWAPGS instruction without waiting for the result of the check, and if the selected branch does not hold up, it discards the result. Thus, there may be a situation where a branch not foreseeing the execution of SWAPGS is speculatively chosen, but during the speculative execution, the value of the GS register is altered by the SWAPGS instruction and used in dependent memory operations, which settle in the CPU cache.
Researchers have proposed two attack scenarios for which prototypes of exploits have been prepared. The first scenario is based on the situation where the SWAPGS instruction is not executed speculatively, although it is used during actual execution, while the second scenario is the opposite, where the SWAPGS instruction is executed speculatively, even though it should not be. Each scenario allows for two exploitation variants: the attacker can either determine the value at a specific address in the kernel space or search for a specific value at random addresses in the kernel. Conducting the attack takes a significant amount of time, and to facilitate the leak, the exploit may need to be executed for several hours.
In the Linux kernel, the issue arises from changing the logic of invoking the SWAPGS instruction (blocking speculative execution), similar to the remedy for other vulnerabilities in the Spectre v1 class. It is assumed that the added protection will have minimal impact on the performance of typical workloads. The delay occurs during the switch between user space and kernel, which may lead to reduced performance, for example, during intensive execution of system calls from an application or frequent generation of NMIs and interrupts.
The fix requires updating the kernel in both the main system and the guest environments, followed by a system reboot. To disable protection in Linux, the option "nospectre_v1" can be used, which also disables measures to block the SWAPGS vulnerability. The fix is available in the form of for the Linux kernel, which is already included in the releases , , 4.14.137, 4.9.188, and 4.4.188. Updates for Linux distributions have not yet been released (, , , , , ). In Windows, the issue was quietly resolved in . Google has the fix for kernel 4.19, provided in ChromeOS and .
According to researchers from Bitdefender, Intel was informed of the issue back in August of last year. The problem was decided to be resolved through software, for which developers from Microsoft, Google, and the Linux kernel were coordinated to develop the fix. Older Intel processors, pre-Ivy Bridge, are much harder 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 by the issue, as they do not support the SWAPGS instruction.
The issue primarily threatens Intel processor owners —
on AMD systems, only the second attack scenario has been reproduced, limited to speculative processing of the basic value of the GS register, which can be used to search for specific values in random memory areas. To block this attack variant, existing protection methods against Spectre v1 vulnerabilities.
Source: opennet.ru
