Intel has released microcode updates for several generations of mobile, desktop, and server CPUs to fix a vulnerability that can be exploited to trigger at the very least a denial-of-service condition, but potentially privilege escalation and information disclosure. The flaw can be exploited if an attacker has local code execution on the operating system, including on guest virtual machines. In a multi-tenant virtualized environment, attackers could exploit the vulnerability from a guest VM to crash the host system, resulting in denial of service for all other guest VMs running on the same server.
Organizations are advised to check for BIOS/UEFI updates with their respective system manufacturers, which should start integrating Intel’s firmware updates. The versions of the patched microcode for every affected Intel CPU are listed in the company’s advisory.
Instruction prefixes that should be ignored but aren’t
The vulnerability is tracked as CVE-2023-23583, but researchers from Google who found and reported the flaw to Intel have also dubbed it Reptar after the common rep instruction prefix.
According to a technical write-up by Google security researcher Tavis Ormandy, the issue stems from the way instruction prefixes are processed on CPUs that support a new feature called fast short repeat move (FSRM). CPU microcode is the low-level code that controls the hardware-level CPU based on the standardized instruction set architecture that is exposed to programmers. The instruction set can be accessed through human-readable machine code code in assembly language.
Writing assembly code means operating directly with CPU instructions and these instructions support a series of prefixes that change the way they work. However, not every prefix applies to every instruction. For example, the code “rep movsb” uses the prefix rep, which means repeat for the instruction movsb that is used to move memory on x86 CPUs from a source to a destination. In the example “rex.rxb rep movsb,” the prefix rex is used to allocate additional bits to the instruction for operands, but the movsb doesn’t need it since all its operands are implicit.
This means that the rex prefix is redundant and meaningless in this scenario, so the CPU microcode will just ignore it — or at least it’s supposed to. What Ormandy and his Google colleagues found is that on CPUs where FSRM is active, these redundant or conflicting prefixes are interpreted in a weird way leading to a security vulnerability.
Why exactly this happens is not entirely clear because the CPU microcode that handles this part is closed source and proprietary, so the researchers didn’t have visibility to such internals. What they observed and could replicate was the CPU crash that resulted in a denial-of-service condition, but they speculated that privilege escalation might also be possible.
Intel flags the vulnerability as privilege escalation
Intel, who also discovered this issue internally via its own engineers, flagged the flaw as a privilege escalation issue, confirming the possibility. They also rated the vulnerability with 8.8 out of 10 severity on the CVSS scale.
“I’m not aware of any documentation that explains exactly how FSRM works, but you can check if you have a processor that supports it by looking at the flags line in /proc/cpuinfo,” Ormandy said. Some of the CPU code names that have the feature include Ice Lake, Rocket Lake, Tiger Lake, Raptor Lake, Alder Lake, and Sapphire Rapids. According to the Intel advisory the affected CPUs include mobile or desktop versions of 10th, 11th, 12th, and 13th generation Intel Core processors, as well as Xeon D and 3rd and 4th generation Xeon Scalable server CPUs.
This is the latest in a long list of CPU vulnerabilities discovered in recent years, including several found this year by Google researchers: Downfall (CVE-2022-40982) and Zenbleed (CVE-2023-20593). Such flaws highlighted why keeping BIOS/UEFI up to date with the latest CPU microcode patches should be part of any enterprise security program.