Vulnerability in Intel processors leading to data leakage through third-party channels

A group of researchers from Chinese and American universities has identified a new vulnerability in Intel processors that leads to the leakage of information about the result of speculative operations through third-party channels, which can be used, for example, to organize a hidden communication channel between processes or detect leaks during Meltdown attacks.

The essence of the vulnerability is that a change in the EFLAGS processor register, which occurred as a result of speculative execution of instructions, affects the subsequent execution time of JCC instructions (jump when specified conditions are met). The speculative operations are not completed and the result is discarded, but the discarded EFLAGS change can be determined by analyzing the execution time of the JCC instructions. Speculatively performed pre-jump comparison operations, if the comparison is successful, result in a small delay that can be measured and used as a feature to match content.

Vulnerability in Intel processors leading to data leakage through third-party channels

Unlike other similar attacks through third-party channels, the new method does not analyze the change in the access time to cached and non-cached data and does not require the stage of resetting the EFLAGS register to the initial state, which makes it difficult to detect and block the attack. As a demonstration, the researchers implemented a variant of the Meltdown attack, using a new method in it to obtain information about the result of a speculative operation. The operation of the method for organizing information leakage during a Meltdown attack has been successfully demonstrated on systems with Intel Core i7-6700 and i7-7700 CPUs in an environment with Ubuntu 22.04 and Linux 5.15 kernel. On a system with an Intel i9-10980XE CPU, the attack was only partially successful.

The 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.

In the classic version of Meltdown, 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 closed memory area, and then in the normally executed code to determine their meaning through analysis of the access time to cached and non-cached data. The new variant uses the change in the EFLAGS register as a marker for a leak. In the Covert Channel demo, one process modulated the data being sent to change the contents of the EFLAGS register, and another process parsed the change in JCC instruction execution time to recreate the data sent by the first process.

Source: opennet.ru

Add a comment