Intel Fixes High-Severity CPU Bug That Causes 'Very Strange Behavior' (arstechnica.com) 22
An anonymous reader quotes a report from Ars Technica: Intel on Tuesday pushed microcode updates to fix a high-severity CPU bug that has the potential to be maliciously exploited against cloud-based hosts. The flaw, affecting virtually all modern Intel CPUs, causes them to "enter a glitch state where the normal rules don't apply," Tavis Ormandy, one of several security researchers inside Google who discovered the bug, reported. Once triggered, the glitch state results in unexpected and potentially serious behavior, most notably system crashes that occur even when untrusted code is executed within a guest account of a virtual machine, which, under most cloud security models, is assumed to be safe from such faults. Escalation of privileges is also a possibility.
The bug, tracked under the common name Reptar and the designation CVE-2023-23583, is related to how affected CPUs manage prefixes, which change the behavior of instructions sent by running software. Intel x64 decoding generally allows redundant prefixes -- meaning those that don't make sense in a given context -- to be ignored without consequence. During testing in August, Ormandy noticed that the REX prefix was generating "unexpected results" when running on Intel CPUs that support a newer feature known as fast short repeat move, which was introduced in the Ice Lake architecture to fix microcoding bottlenecks. The unexpected behavior occurred when adding the redundant rex.r prefixes to the FSRM-optimized rep mov operation. [...]
Intel's official bulletin lists two classes of affected products: those that were already fixed and those that are fixed using microcode updates released Tuesday. An exhaustive list of affected CPUs is available here. As usual, the microcode updates will be available from device or motherboard manufacturers. While individuals aren't likely to face any immediate threat from this vulnerability, they should check with the manufacturer for a fix. People with expertise in x86 instruction and decoding should read Ormandy's post in its entirety. For everyone else, the most important takeaway is this: "However, we simply don't know if we can control the corruption precisely enough to achieve privilege escalation." That means it's not possible for people outside of Intel to know the true extent of the vulnerability severity. That said, anytime code running inside a virtual machine can crash the hypervisor the VM runs on, cloud providers like Google, Microsoft, Amazon, and others are going to immediately take notice.
The bug, tracked under the common name Reptar and the designation CVE-2023-23583, is related to how affected CPUs manage prefixes, which change the behavior of instructions sent by running software. Intel x64 decoding generally allows redundant prefixes -- meaning those that don't make sense in a given context -- to be ignored without consequence. During testing in August, Ormandy noticed that the REX prefix was generating "unexpected results" when running on Intel CPUs that support a newer feature known as fast short repeat move, which was introduced in the Ice Lake architecture to fix microcoding bottlenecks. The unexpected behavior occurred when adding the redundant rex.r prefixes to the FSRM-optimized rep mov operation. [...]
Intel's official bulletin lists two classes of affected products: those that were already fixed and those that are fixed using microcode updates released Tuesday. An exhaustive list of affected CPUs is available here. As usual, the microcode updates will be available from device or motherboard manufacturers. While individuals aren't likely to face any immediate threat from this vulnerability, they should check with the manufacturer for a fix. People with expertise in x86 instruction and decoding should read Ormandy's post in its entirety. For everyone else, the most important takeaway is this: "However, we simply don't know if we can control the corruption precisely enough to achieve privilege escalation." That means it's not possible for people outside of Intel to know the true extent of the vulnerability severity. That said, anytime code running inside a virtual machine can crash the hypervisor the VM runs on, cloud providers like Google, Microsoft, Amazon, and others are going to immediately take notice.
Re: (Score:3)
You mean placed to please some TLA customer (I hear the NSA buys a _lot_ of CPUs...) and in the hopes nobody finds it?
Placing something of this extreme magnitude would be quite reckless, so I tend to incompetence as root-cause instead. But I have zero trust in Intel, so I would not rule it out. Maybe a small, hard to find backdoor designed incompetently resulting in something much larger?
Re: (Score:2)
Re: (Score:2)
Indeed.
Re: (Score:2)
All Hail Reptar! (Score:5, Informative)
Technical details are on the researcher's blog: https://lock.cmpxchg8b.com/rep... [cmpxchg8b.com]
Re: (Score:3)
I ain't clicking that shit!
That's the same link as is referenced in the Ars Technica article, so I guess it's the same as following most other links on the internet or from Slashdot summaries. Possibly better because at least we know the author knows something about security from the stuff they found and that they probably can't afford to be caught hacking random internet users from the area they work in.
intel only way to keep up with AMD is to put in (Score:1)
intel only way to keep up with AMD is to put in buggy stuff that make our cpus fast.
Now how much of an CPU% hit will this fix take up?
Re:intel only way to keep up with AMD is to put in (Score:4, Interesting)
I would expect this one to be fairly mild -- it's entirely conceivable that this is a microcode bug to begin with and the fix would be approximately zero cost. At worst I'd expect the cost to be disabling the FSRM optimization.
Re: (Score:2)
Not sure the fix will cost much. But a bug of this extreme severity points strongly to hasty slap-dash design that does not meet any reasonable standards.
Re: (Score:2)
This bug might be the first one of a category of new bugs in Intel cpus.
Re: (Score:2)
Exactly. If the design process is compromised this badly (incompetence, intent, malice) that is a very reasonable assumption as the bad process will have been applied to more things.
Re: (Score:3)
This is a bug in "the software of hardware" to quote Errol. Firstly that's good because it shows that the actual hardware designers had got this right so that it can be fixed. The idea of having hardware software (firmware???) is that you can fix it more cheaply so bugs are not as expensive and long term problematic as if you made the same mistake in real hardware.
Secondly, this likely shows that Intel's people know all about that trade off and have saved money on their hardware software by putting it out w
Re: intel only way to keep up with AMD is to put i (Score:2)
I completly agree. Although all my own systems are AMD these days.
Re: (Score:2)
Re: (Score:1)
Then why are you still here m8?
Let's fix it in ... (Score:2)
Lets fix it in hardware!
Lets fix it in the software of hardware!