Intel has launched microcode updates for a number of generations of cellular, desktop, and server CPUs to repair a vulnerability that may be exploited to set off on the very least a denial-of-service situation, however probably privilege escalation and data disclosure. The flaw will be exploited if an attacker has native code execution on the working system, together with on visitor digital machines. In a multi-tenant virtualized atmosphere, attackers may exploit the vulnerability from a visitor VM to crash the host system, leading to denial of service for all different visitor VMs working on the identical server.
Organizations are suggested to verify for BIOS/UEFI updates with their respective system producers, which ought to begin integrating Intel’s firmware updates. The variations of the patched microcode for each affected Intel CPU are listed within the firm’s advisory.
Instruction prefixes that needs to be ignored however aren’t
The vulnerability is tracked as CVE-2023-23583, however researchers from Google who discovered and reported the flaw to Intel have additionally dubbed it Reptar after the frequent rep instruction prefix.
In line with a technical write-up by Google safety researcher Tavis Ormandy, the problem stems from the best way instruction prefixes are processed on CPUs that help a brand new function referred to as quick brief repeat transfer (FSRM). CPU microcode is the low-level code that controls the hardware-level CPU primarily based on the standardized instruction set structure that’s uncovered to programmers. The instruction set will be accessed by way of human-readable machine code code in meeting language.
Writing meeting code means working immediately with CPU directions and these directions help a sequence of prefixes that change the best way they work. Nevertheless, not each prefix applies to each instruction. For instance, the code “rep movsb” makes use of the prefix rep, which suggests repeat for the instruction movsb that’s used to maneuver reminiscence on x86 CPUs from a supply to a vacation spot. Within the instance “rex.rxb rep movsb,” the prefix rex is used to allocate extra bits to the instruction for operands, however the movsb doesn’t want it since all its operands are implicit.
Which means that the rex prefix is redundant and meaningless on this state of affairs, so the CPU microcode will simply ignore it — or at the very least it’s purported to. What Ormandy and his Google colleagues discovered is that on CPUs the place FSRM is lively, these redundant or conflicting prefixes are interpreted in a bizarre means resulting in a safety vulnerability.
Why precisely this occurs just isn’t totally clear as a result of the CPU microcode that handles this half is closed supply and proprietary, so the researchers didn’t have visibility to such internals. What they noticed and will replicate was the CPU crash that resulted in a denial-of-service situation, however they speculated that privilege escalation may also be potential.
Intel flags the vulnerability as privilege escalation
Intel, who additionally found this challenge internally through its personal engineers, flagged the flaw as a privilege escalation challenge, confirming the chance. In addition they rated the vulnerability with 8.8 out of 10 severity on the CVSS scale.
“I am not conscious of any documentation that explains precisely how FSRM works, however you may verify when you’ve got a processor that helps it by trying on the flags line in /proc/cpuinfo,” Ormandy stated. A number of the CPU code names which have the function embrace Ice Lake, Rocket Lake, Tiger Lake, Raptor Lake, Alder Lake, and Sapphire Rapids. In line with the Intel advisory the affected CPUs embrace cellular or desktop variations of 10th11th12thand 13th era Intel Core processors, in addition to Xeon D and threerd and 4th era Xeon Scalable server CPUs.
That is the newest in an extended record of CPU vulnerabilities found lately, together with a number of discovered this yr by Google researchers: Downfall (CVE-2022-40982) and Zenbleed (CVE-2023-20593). Such flaws highlighted why conserving BIOS/UEFI updated with the newest CPU microcode patches needs to be a part of any enterprise safety program.
