CROSSTalk a data leak vulnerability what if… it affects Intel

intel bug

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

intel bug
Related article:
A new vulnerability was discovered in Intel processors and cannot be fixed

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

intel-zombieload
Related article:
Zombieload 2.0 a new attack method that only affects Intel processors

The content of the article adheres to our principles of editorial ethics. To report an error click here!.

A comment, leave yours

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.

  1.   Nacho said

    The headline is not understood, where three points go, a comma should go, and, yes, that "yes" has an accent.