Tavis Ormandy, a security researcher at Google, has identified a new vulnerability (CVE-2023-23583) in Intel processors, codenamed Reptar, which mainly poses a threat to cloud systems running virtual machines of different users. The vulnerability allows the system to hang or crash when certain operations are performed on unprivileged guest systems. To test your systems, a utility has been published that creates conditions for the manifestation of vulnerabilities.
Theoretically, the vulnerability can be used to escalate privileges from the third to the zero protection ring (CPL0) and escape from isolated environments, but this scenario has not yet been confirmed in practice due to the difficulties of debugging at the microarchitectural level. An internal review at Intel also showed the potential for exploitation of the vulnerability to escalate privileges under certain conditions.
According to the researcher, the vulnerability is present in the Intel Ice Lake, Rocket Lake, Tiger Lake, Raptor Lake, Alder Lake and Sapphire Rapids processor families. The Intel report mentions that the problem appears starting from the 10th generation (Ice Lake) of Intel Core processors and the third generation of Xeon Scalable processors, as well as in Xeon E/D/W processors (Ice Lake, Skylake, Haswell, Broadwell, Skylake, Sapphire Rapids, Emerald Rapids, Cascade Lake, Cooper Lake, Comet Lake, Rocket Lake) and Atom (Apollo Lake, Jasper Lake, Arizona Beach, Alder Lake, Parker Ridge, Snow Ridge, Elkhart Lake and Denverton). The vulnerability in question was fixed in yesterday's microcode update 20231114.
The vulnerability is caused by the fact that under certain microarchitectural circumstances, the execution of the βREP MOVSBβ instruction is encoded with an excessive βREXβ prefix, which leads to undefined behavior. The problem was discovered during testing of redundant prefixes, which in theory should be ignored, but in practice led to strange effects, such as ignoring unconditional branches and breaking pointer saving in the xsave and call instructions. Further analysis showed that adding a redundant prefix to the "REP MOVSB" instruction causes corruption of the contents of the ROB (ReOrder Buffer) buffer used to order instructions.
It is believed that the error is caused by an incorrect calculation of the size of the "MOVSB" instruction, which leads to the violation of the addressing of instructions written to the ROB buffer after the MOVSB ββwith an excessive prefix, and the offset of the instruction pointer. Such desynchronization can be limited to disruption of intermediate calculations with subsequent restoration of the integral state. But if you crash multiple cores or SMT threads at the same time, you can damage the microarchitectural state enough to crash.
Source: opennet.ru