Simply Intel has continued to be the target of various vulnerabilities that lead to data leakage and we have talked a lot about them here on the blog And in this new one, Intel is still no exception.
And is that a team of researchers from the Free University of Amsterdam ha identified a new vulnerability (CVE-2020-0543) in microarchitecture structures of Intel processors, which is notable for the fact that allows you to restore the results of some instructions run on another CPU core.
This is the first vulnerability of the mechanism of speculative execution of instructions, allowing data leakage between separate CPU cores (Previously, leaks were limited to different threads of a kernel.)
Los investigadores they called the problem CROSSTalk, but Intel docs refer to the vulnerability as SRBDS (Sample Special Register Buffer Data).
About CROSSTalk
The vulnerability belongs to the class of MDS problems, introduced a year ago, and is based on the application of third-party analysis methods to data in microarchitecture structures.
The CROSSTalk principle is close to RIDL vulnerability, but differs in the source of the leak. The new vulnerability manipulates an intermediate buffer leak previously undocumented which is shared between all CPU cores.
The gist of the problem is that some microprocessor instructions, including RDRAND, RDSEED, and SGX EGETKEY, are implemented using the SRR (Special Register Reads) internal microarchitecture operation.
On vulnerable processors, the data returned for SRR is put into an intermediate buffer common to all CPU cores, after which it is transferred to the population buffer associated with the specific physical core of the CPU on which the startup starts. read operation. Then, from the padding buffer, the value is copied to registers visible to applications.
The size of the intermediate shared buffer corresponds to the cache line, what is generally larger than the size of the data read and different read operations affect different offsets in the buffer.
Because the shared buffer is copied to the entire fill buffer, not only the portion required for the current operation is moved, but also the remaining data from other operations, including those performed on other CPU cores.
If the attack is organized successfully, a local user authenticated on the system can determine the outcome executing the RDRAND, RDSEED and EGETKEY instructions in a strange process or within the Intel SGX enclave, regardless of the CPU core the code is running on.
Los investigadores who discovered the problem published an exploit prototype that demonstrated the possibility of leaking information on random values obtained through the RDRAND and RDSEED instructions to restore the ECDSA private key processed in the Intel SGX enclave after performing only one digitally signed operation on the system.
This demonstrated that a wide range of Intel desktop, mobile and server processors, including Core i3, i5, i7, i9, m3, Celeron, Atom, Xeon, Scalable Xeon, etc., are vulnerable.
It is noteworthy that Intel was notified of the vulnerability in September 2018 and a prototype exploit was provided in July 2019 that showed a data leak between the CPU cores, but the development of the solution was delayed due to the complexity of its implementation.
In today's proposed microcode update, the problem is blocked by changing the behavior of the instructions RDRAND, RDSEED, and EGETKEY to overwrite the data in the shared buffer to prevent residual information from settling in it.
Additionally, buffer access suspension applies until read and write operations are complete.
A side effect of this protection is an increase in delays when RDRAND, RDSEED, and EGETKEY are executed, and a reduction in performance when trying to execute these instructions simultaneously on different logical processors. These features can adversely affect the performance of some applications.
Source: https://www.vusec.net
A comment, leave yours
The headline is not understood, where three points go, a comma should go, and, yes, that "yes" has an accent.