Google and Intel fuzz, find and fix a fabulous bug. Next up: More of the same.

Google has been fuzzing Intel CPU instructions, looking for security holes. And, it’s emerged, they found an absolute doozy—many processors from the last three years are vulnerable.

Codenamed Reptar, it can cripple entire cloud environments. In today’s SB Blogwatch, we run for the hills.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Reptar origins.

IaaS Catch Fire

What’s the craic? Thomas Claburn reports—“Out-of-band patch addresses privilege escalation flaw”:

“CVE-2023-23583”
The flaw, designated INTEL-SA-00950 and given a CVSS 3.0 score of 8.8 out of 10, affects Intel Sapphire Rapids, Alder Lake, and Raptor Lake chip families. It’s being addressed with a microcode update as part of Intel’s Patch Tuesday bundle of 31 security advisories that cover 104 CVEs.
…
A Google researcher reported finding the same denial of service flaw that Intel’s researchers had found internally. Citing a 90-day disclosure policy, Google planned to reveal its findings on November 14, 2023. … And here we are. Google calls the vulnerability Reptar (CVE-2023-23583).

Which chips are vulnerable? Sergiu Gatlan explains—“New Reptar CPU flaw impacts Intel desktop and server systems”:

“Microcode updates”
Intel has fixed a high-severity CPU vulnerability in its modern desktop, server, mobile, and embedded CPUs. … Described as a ‘Redundant Prefix Issue,’ … attackers can exploit the flaw … to escalate privileges, gain access to sensitive information, or trigger a denial of service state (something that could prove very costly for cloud providers).
…
[Some] systems with affected processors, including those with Alder Lake, Raptor Lake, and Sapphire Rapids, have already received updated microcode … with no performance impact observed or expected issues. The company also released microcode updates to address the issue for the other CPUs, with users advised to update their BIOS, system OS, and drivers to receive the latest microcode from their original equipment manufacturer, … operating system vendor … and hypervisor vendor.

It’s that man again. Blame Tavis Ormandy for the panic—“Reptar”:

“Privilege escalation”
We have a CPU mystery! We found a way to cause some processors to enter a glitch state where the normal rules don’t apply. … In August, our validation pipeline … found a case where adding redundant rex.r prefixes to an FSRM optimized rep movs operation seemed to cause unpredictable results. … For example, branches to unexpected locations.
…
This already seemed like it could be indicative of a serious problem, but [then] we found that when multiple cores were triggering the same bug, the processor would … halt. We verified this worked even inside an unprivileged guest VM, so this already has serious security implications for cloud providers.
…
We know that we can corrupt the system state badly enough to cause machine check errors, and we’ve also observed threads interfere with execution of processes. … However, we simply don’t know if we can control the corruption precisely enough to achieve privilege escalation. [But] I suspect that it is possible.

Explain “Prefixes” please? ajross has a go:

“Prefixes” in this case mostly expand the instruction encoding space. … Rarely-used addressing modes get a “segment prefix” that causes them to use a segment other than DS. Or x86_64 added a “REX” prefix that added more bits to the register fields allowing for 16 [registers].
…
Notably the “REP” prefix in question turns out to be the one exception. This is a microcoded repeat prefix left over from the ancient days. But it [is] performance-sensitive … so it’s worthwhile for CPU vendors to continue to optimize them. Which is how the bug in question seems to have happened.

Clear as mud. Needleroozer tries, too:

Intel allows x86 assembly instructions to have a “rex.rbx” prefix that allows a wider range of registers to be addressed by a given instruction. In certain cases you can set up a “movsb” move operation that takes no register operands.
…
Ice Lake (10th-generation) processors introduced an optimization called FSRM (Fast Short Repeat Move) that uses this. If you put a “rex.rbx” prefix on a “movsb” instruction with no register operands, it should be ignored, because it’s redundant. … However, if that “movsb” happens to have been optimized with FSRM, something gets screwy and the CPU loses track.

This feels like something quite new. devloop ponders what comes next:

A discovered bug usually points to a possible cluster of undiscovered bugs. This bug might be the first one of a category of new bugs in Intel CPUs.

How can this be exploited in IaaS? Read dgacmu and weep:

It would let you mount a really nasty DoS on cloud providers by triggering hard resets of the physical machines. … Particularly since [it] could prevent an automatic reboot.
…
You can exploit this from a single core shared instance: … Go and find yourself a thousand cheap/free-tier accounts, spin up an instance in a few regions each, and boom, you’ve taken out 10K physical hosts. … Causing a near simultaneous reboot of enough hosts is likely to take other parts of the infrastructure down. … Being able to possibly take out a cloud provider for a while is … monetizable.

So we all need to go look for a BIOS update? No, says Jeff S:

Most OSes have the ability to update the CPU microcode, so it probably doesn’t matter what BIOS you use. Windows, Linux, FreeBSD all can.
…
I haven’t checked other *BSD flavors, but if FreeBSD can, there’s a good chance the others can too. I’m not positive if Apple can on Intel Macs, but I would be extremely surprised if … not.

Meanwhile, an opcode causing a CPU to simply halt is nuttin’. This Anonymous Coward wishes you to exit their grassed area:

Try exploiting the HCF instruction.

And Finally:

But why Reptar?

Hat tip: Lammy

Previously in And Finally

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi, @richij or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: Funko Pop