Reptar, a vulnerability that affects Intel processors 

vulnerability

If exploited, these flaws can allow attackers to gain unauthorized access to sensitive information or generally cause problems

Recently a Google security researcher revealed, through a blog post, the discovery of a new vulnerability (CVE-2023-23583) on Intel processors, codenamed Reptar, which affects several Intel desktop, mobile and server CPUs, but especially cloud systems running different users' virtual machines.

Vulnerability “Reptar” allows the system to hang or crash when performing certain operations on unprivileged guest systems. Theoretically, the vulnerability can be used to escalate privileges from the third protection ring to zero (CPL0) and escape from isolated environments, but this scenario has not yet been confirmed in practice due to debugging difficulties at the microarchitecture level.

Google's information security engineering team reported the vulnerability to Intel, who disclosed it today. Through careful collaboration between Google, Intel, and industry partners, mitigations have been implemented and Google employees and our customers are protected.

According to the researcher, The vulnerability is present in a large number of Intel processor families and the problem is reported to appear on XNUMXth generation Intel Core processors and XNUMXrd generation Xeon Scalable processors, as well as on Xeon E/D/W processors.

About Reptar

It is mentioned that the vulnerability is due to the fact that the execution of a "REP MOVSB" instruction encoded with a "REX" prefix Redundant (a single-byte prefix) results in undefined behavior. The REX prefix can provide additional bits to the next instruction to use as operands, thus allowing all 16 possible general-purpose registers to be encoded, and these optional bits give room to encode more general-purpose registers in the next instruction.

In August, our validation process produced an interesting claim. He found a case where adding redundant REX prefixes to an optimized FSRM "rep movs" operation seemed to cause unpredictable results.

We observed some very strange behavior during testing. For example, branches to unexpected locations, unconditional branches that are ignored, and the processor no longer accurately records the instruction pointer xsaveo call instructions.

Interestingly, when trying to understand what was happening, we were seeing a debugger reporting impossible states.

The issue was discovered during redundant prefix testing, which in theory should be ignored, but in practice caused strange effects, such as ignoring unconditional branches and breaking pointer saving in xsave and call instructions. Further analysis showed that adding a redundant prefix to the “REP MOVSB” instruction causes corruption in the contents of the ROB (ReOrder Buffer) buffer used to order instructions.

An interesting feature of x86 is that instruction decoding is generally quite relaxed. If you use a prefix that doesn't make sense or conflicts with other prefixes, nothing much will happen, it will usually just be ignored.

This fact is sometimes useful; Compilers can use redundant prefixes to pad a single instruction up to a desirable alignment limit.

The error is believed to be due to an incorrect calculation of the size of the "MOVSB" instruction with excessive prefix, which leads to a violation of the addressing of instructions written to the ROB buffer after MOVSB ​​​​and displacement of the instruction pointer.

This desynchronization can be limited to the interruption of intermediate calculations with subsequent restoration of the integral state. But if you block multiple cores or SMT threads at the same time, it can cause enough damage to the state of the microarchitecture to cause it to crash.

An internal Intel review also showed the potential for the vulnerability to be exploited to escalate privileges under certain conditions.

Finally, it is worth mentioning that to test the integrity of the systems, a utility has been published which creates the conditions for the manifestation of vulnerabilities, in addition to the fact that the vulnerability in question was fixed in the microcode update 20231114.

If you are interested in knowing more about it, you can check the details in the following link.


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.