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.
