New Spectre V2 Attack Impacts Linux Systems On Intel CPUs (bleepingcomputer.com) 21
An anonymous reader shared this report from BleepingComputer:
Researchers have demonstrated the "first native Spectre v2 exploit" for a new speculative execution side-channel flaw that impacts Linux systems running on many modern Intel processors. Spectre V2 is a new variant of the original Spectre attack discovered by a team of researchers at the VUSec group from VU Amsterdam. The researchers also released a tool that uses symbolic execution to identify exploitable code segments within the Linux kernel to help with mitigation.
The new finding underscores the challenges in balancing performance optimization with security, which makes addressing fundamental CPU flaws complicated even six years after the discovery of the original Spectre....
As the CERT Coordination Center (CERT/CC) disclosed yesterday, the new flaw, tracked as CVE-2024-2201, allows unauthenticated attackers to read arbitrary memory data by leveraging speculative execution, bypassing present security mechanisms designed to isolate privilege levels. "An unauthenticated attacker can exploit this vulnerability to leak privileged memory from the CPU by speculatively jumping to a chosen gadget," reads the CERT/CC announcement. "Current research shows that existing mitigation techniques of disabling privileged eBPF and enabling (Fine)IBT are insufficient in stopping BHI exploitation against the kernel/hypervisor."
"For a complete list of impacted Intel processors to the various speculative execution side-channel flaws, check this page updated by the vendor."
The new finding underscores the challenges in balancing performance optimization with security, which makes addressing fundamental CPU flaws complicated even six years after the discovery of the original Spectre....
As the CERT Coordination Center (CERT/CC) disclosed yesterday, the new flaw, tracked as CVE-2024-2201, allows unauthenticated attackers to read arbitrary memory data by leveraging speculative execution, bypassing present security mechanisms designed to isolate privilege levels. "An unauthenticated attacker can exploit this vulnerability to leak privileged memory from the CPU by speculatively jumping to a chosen gadget," reads the CERT/CC announcement. "Current research shows that existing mitigation techniques of disabling privileged eBPF and enabling (Fine)IBT are insufficient in stopping BHI exploitation against the kernel/hypervisor."
"For a complete list of impacted Intel processors to the various speculative execution side-channel flaws, check this page updated by the vendor."
Actual article available at... (Score:5, Informative)
Hard to fathom (Score:2)
It's hard to understand why speculative execution information and control mechanisms are available to user mode processes at all. It would seem like an obvious hole. Who would need this information other than the microcode?
Re:Hard to fathom (Score:4, Informative)
Spectre [wikipedia.org] is an information leak through a side channel. The attacker tricks other code (such as the kernel) into making a branch that is followed by code that affects the CPU state based on secret information -- such as loading value X into the cache if some secret bit is 1. The CPU will erase the effect of the speculatively executed code on registers, but not the cache, so the attacker can see how long it takes to load value X after the vulnerable "widget" runs.
The information leak is not nearly as direct as you seem to think it is.
Re: (Score:2)
Thank you. This sounds TEMPEST-y now that you explain it. Turning off speculative execution seems to be the only ironclad solution.
Re: Hard to fathom (Score:4, Informative)
Unfortunately you canâ(TM)t disable speculative execution. Itâ(TM)s been relied on to make CPUs fast since at least the pentium, perhaps the 486? For sure the pentium.
Itâ(TM)s based on some very old research from the 70â(TM)s (?), but back then they called it super scalar architecture.
Intel isnâ(TM)t the only one who does speculative execution. Most ARM platforms do as well, even all the way down to things like your smart watch.
The real issue that keeps tripping up intel is the effects on CPU cache are preserved after the âoespeculative executed codeâ is disposed of.
The simplest way to think of this is: you create an array of 256 elements. Then you preform an action to flush all that out of CPU cache. Then you trick the CPU to read a byte that it shouldnâ(TM)t read for you because you donâ(TM)t have the privileges to read that byte, and inside the speculative branch you read back into cache the offset in the array that matches the byte value.
Then, outside the speculative branch you read the entire array and time access speed. The array element that read fast was in the cache and is the value of the byte you shouldnâ(TM)t have been able to read.
The part of the speculative execution engine that undoes the work done in a branch that should not have been followed, at a minimum, probably needs to be extended to reverse effects on cache too. But thatâ(TM)s probably very hard to do in silicon.
Re: (Score:2)
Unfortunately you can't disable speculative execution. It's been relied on to make CPUs fast since at least the pentium, perhaps the 486? For sure the pentium.
Well one can turn of SMT in the BIOS, AFAIK that will prevent Spectre. That is what OpenBSD does. OpenBSD disables SMT via sysctl(8) switch "hw.smt" even on systems that do not allow disabling in the "BIOS".
But I heard this will impact servers in a big way. I guess this is what we get by allowing Companies to take directions from MBAs instead of engineers. The rush to market that all Companies shoulders the main blame.
Re: Hard to fathom (Score:4, Informative)
Well one can turn of SMT in the BIOS, AFAIK that will prevent Spectre.
No, it will not.
It will mitigate against a couple of known HT-specific leaks.
That is what OpenBSD does. OpenBSD disables SMT via sysctl(8) switch "hw.smt" even on systems that do not allow disabling in the "BIOS".
Yes, because of those HT leaks, not Spectre in general.
Linux shuts it down if your cpu has a vulnerable HT implementation in silicon.
But I heard this will impact servers in a big way. I guess this is what we get by allowing Companies to take directions from MBAs instead of engineers. The rush to market that all Companies shoulders the main blame.
Every mitigation has a cost. Unfortunately, it'll be a long time before we've really gotten a grasp on closing up side channel attacks.
You can't blame the MBAs for this.
Engineers were never trying to harden their devices against side-channel attacks previously.
Re: (Score:2)
Engineers were never trying to harden their devices against side-channel attacks previously.
Well, we were. Just no this type. It was assumed to be impossible on generic CPUs, but timing attacks have been used against ATMs, bank vaults, and various dedicated security hardware since the 90s.
Re: (Score:2)
Timing attacks in general are nothing new.
Exploiting previously undescribed behavior in the the microarchitecture of CPUs with them is.
Re: (Score:2)
Unfortunately you canÃ(TM)t disable speculative execution. ItÃ(TM)s been relied on to make CPUs fast since at least the pentium, perhaps the 486? For sure the pentium.
486 is not superscalar. Pentium is. Am586 was not either, it is basically a 486 on 'roids. K6 is.
Re: (Score:2)
It's hard to understand why speculative execution information and control mechanisms are available to user mode processes at all.
That information is not intentionally made available to user mode processes. Essentially, all the SPECTRE type side-channel attacks exploit that the time certain normal user mode instructions take differs, depending on what other users or the kernel do on the same CPU.
Re:Hard to fathom (Score:4, Informative)
It's nothing to do with user code getting at speculative execution information.
It's about the side channel attacks that are inadvertently made available due to speculation.
For example, let's say you are trying to determine where some code is executing - perhaps it's an encryption operation. You could code up something that trashes the cache. Then you can start poking at access times to hit certain functions in memory. If speculative execution tries to access a branch in the code, then when you time the results of accessing that code, it would be dramatically lower than if it was loaded from RAM.
This is because the speculative execution would have loaded code and data from RAM into the cache. Then if the speculation failed, the results are tossed away. But the fact remains - code and data was still loaded in the cache, which means if you attempt to time how long it takes to load that code or data, suddenly it decreases because it's already in cache.
It's all side channel attacks to get at the information, not something that the processor directly reveals. That's pretty much why Spectre attacks are multi-architecture - they are not limited but affect all speculative and out of order execution architectures. Spectre attacks happen not just on Intel, but AMD processors and even ARM processors. The latest one attacking Apple's M series processors is again the same thing (the processor has a hardware block that snoops the registers for things that look like pointers and then pre-emptively loads them into cache. This can speed up execution because the cache will be pre-loaded with contents of main memory so when the processor does a memory access it's already there in cache. Of course, the problem is it's also a side channel attack in that timing can reveal what got loaded into cache.
Emerald Rapids affected (Score:2)
Intel's latest and greatest datacentre product is vulnerable. Lol!
Re: (Score:2)
It's still problematic, but its about 194 times slower than on former-generation parts.
This is similar to RetBleed, where Intel parts had a speculation window capable of about 219 bytes per second, or about 17 times less than the affected AMD parts.
AMD (Score:3)
What about AMD? I tend to prefer AMD EPYC-powered workloads because they're slightly cheaper.
Re: (Score:2)
In this case, it would appear that modern AMD CPUs are not affected.
Re: (Score:2)
The impacted cpu's list above only included Intel parts. The article doesn't mention AMD at all.
Best,
Re: (Score:2)
However, there's a good chance it still will be.
BHI was only narrowly guarded against on impacted Intel and AMD parts via disabling eBPF.
Retpolines were shown to still be vulnerable on AMD parts, so they have adopted eIBRS (what Intel parts were using to begin with).
It's only a matter of time before someone finds a native BHI hit for eIBRS-using AMD parts.
There's no winning this fuckery.
Re: (Score:3)
Linux kernel 6.8.6 includes BHI mitigation. For my AMD Zen3 processor, dmesg says "Not affected".
Re: (Score:2)
This was famously egg in the face of AMD and Torvalds who mocked the IBRS solution (torvalds), or said it wasn't needed (AMD), when it ended up being the only one effective.