Intel fixes high-severity CPU bug that causes “very strange behavior”


Intel on Tuesday pushed microcode updates to repair a high-severity CPU bug that has the potential to be maliciously exploited in opposition to cloud-based hosts.

The flaw, affecting just about all fashionable Intel CPUs, causes them to “enter a glitch state the place the traditional guidelines don’t apply,” Tavis Ormandy, certainly one of a number of safety researchers inside Google who found the bug, reported. As soon as triggered, the glitch state ends in surprising and doubtlessly critical habits, most notably system crashes that happen even when untrusted code is executed inside a visitor account of a digital machine, which, beneath most cloud safety fashions, is assumed to be protected from such faults. Escalation of privileges can be a chance.

Very unusual habits

The bug, tracked beneath the frequent title Reptar and the designation CVE-2023-23583, is said to how affected CPUs handle prefixes, which change the habits of directions despatched by working software program. Intel x64 decoding typically permits redundant prefixes—that means people who don’t make sense in a given context—to be ignored with out consequence. Throughout testing in August, Ormandy seen that the REX prefix was producing “surprising outcomes” when working on Intel CPUs that help a more moderen function often known as quick brief repeat transfer, which was launched within the Ice Lake structure to repair microcoding bottlenecks.

The surprising habits occurred when including the redundant rex.r prefixes to the FSRM-optimized rep mov operation. Ormandy wrote:

We noticed some very unusual habits whereas testing. For instance, branches to surprising places, unconditional branches being ignored and the processor now not precisely recording the instruction pointer in xsave or name directions.

Oddly, when attempting to grasp what was taking place we’d see a debugger reporting inconceivable states!

This already appeared prefer it could possibly be indicative of a major problem, however inside a couple of days of experimenting we discovered that when a number of cores have been triggering the identical bug, the processor would start to report machine examine exceptions and halt.

We verified this labored even inside an unprivileged visitor VM, so this already has critical safety implications for cloud suppliers. Naturally, we reported this to Intel as quickly as we confirmed this was a safety difficulty.

Jerry Bryant, Intel’s senior director of Incident Response & Safety Communications, mentioned on Tuesday that firm engineers have been already conscious of a “purposeful bug” in older CPU platforms that might lead to a short lived denial of service and had scheduled a repair for subsequent March. The severity score had tentatively been set at 5 out of a doable 10. These plans have been disrupted following discoveries inside Intel and later inside Google. Bryant wrote:

Because of the diligence and experience of Intel safety researchers, a vector was later found that might permit a doable escalation of privilege (EoP). With an up to date CVSS 3.0 rating of 8.8 (excessive), this discovery modified our method to mitigating this difficulty for our clients and we pulled the replace ahead to align with disclosures already deliberate for November 2023.

Whereas getting ready the February 2024 Intel Platform Replace bundle for buyer validation, we obtained a report from a Google researcher for a similar TDoS difficulty found internally. The researcher cited a Google 90 day disclosure coverage and that they might go public on November 14, 2023.

Disaster (hopefully) averted

Google labored with trade companions to establish and check a profitable mitigation so all customers are shielded from this danger in a well timed method. Particularly, Google’s response crew ensured a profitable rollout of the mitigation to our methods earlier than it posed a danger to our clients, primarily Google Cloud and ChromeOS clients.

Intel’s official bulletin lists two courses of affected merchandise: people who have been already mounted and people which can be mounted utilizing microcode updates launched Tuesday. Particularly, these merchandise have the brand new microcode replace:

Product Assortment Vertical Phase CPU ID Platform ID
tenth Era Intel Core Processor Household Cellular 706E5 80
third Era Intel Xeon Processor Scalable Household Server 606A6 87
Intel Xeon D Processor Server 606C1 10
eleventh Era Intel Core Processor Household Desktop


A0671 02
eleventh Era Intel Core Processor Household Cellular








Intel Server Processor Server


A0671 02

An exhaustive checklist of affected CPUs is out there here. As typical, the microcode updates shall be obtainable from gadget or motherboard producers. Whereas people aren’t more likely to face any quick risk from this vulnerability, they need to examine with the producer for a repair.

Individuals with experience in x86 instruction and decoding ought to learn Ormandy’s publish in its entirety. For everybody else, an important takeaway is that this: “Nonetheless, we merely don’t know if we are able to management the corruption exactly sufficient to attain privilege escalation.” Meaning it’s not doable for individuals outdoors of Intel to know the true extent of the vulnerability severity. That mentioned, anytime code working inside a digital machine can crash the hypervisor the VM runs on, cloud suppliers like Google, Microsoft, Amazon, and others are going to right away take discover.

In a separate publish, Google officers wrote:

The impression of this vulnerability is demonstrated when exploited by an attacker in a multi-tenant virtualized setting, because the exploit on a visitor machine causes the host machine to crash leading to a Denial of Service to different visitor machines working on the identical host. Moreover, the vulnerability might doubtlessly result in data disclosure or privilege escalation.

The publish mentioned that Google labored with trade companions to establish and check profitable mitigations which have been rolled out. It’s probably any potential disaster has now been averted, at the least within the largest cloud environments. Smaller cloud companies should have work to do.

Source link