Spectre Flaws Still Haunt Intel, AMD as Researchers Found Fresh Attack Method (theregister.com) 12
"Six years after the Spectre transient execution processor design flaws were disclosed, efforts to patch the problem continue to fall short," writes the Register:
Johannes Wikner and Kaveh Razavi of Swiss University ETH Zurich on Friday published details about a cross-process Spectre attack that derandomizes Address Space Layout Randomization and leaks the hash of the root password from the Set User ID (suid) process on recent Intel processors. The researchers claim they successfully conducted such an attack.... [Read their upcomong paper here.] The indirect branch predictor barrier (IBPB) was intended as a defense against Spectre v2 (CVE-2017-5715) attacks on x86 Intel and AMD chips. IBPB is designed to prevent forwarding of previously learned indirect branch target predictions for speculative execution. Evidently, the barrier wasn't implemented properly.
"We found a microcode bug in the recent Intel microarchitectures — like Golden Cove and Raptor Cove, found in the 12th, 13th and 14th generations of Intel Core processors, and the 5th and 6th generations of Xeon processors — which retains branch predictions such that they may still be used after IBPB should have invalidated them," explained Wikner. "Such post-barrier speculation allows an attacker to bypass security boundaries imposed by process contexts and virtual machines." Wikner and Razavi also managed to leak arbitrary kernel memory from an unprivileged process on AMD silicon built with its Zen 2 architecture.
Videos of the Intel and AMD attacks have been posted, with all the cinematic dynamism one might expect from command line interaction.
Intel chips — including Intel Core 12th, 13th, and 14th generation and Xeon 5th and 6th — may be vulnerable. On AMD Zen 1(+) and Zen 2 hardware, the issue potentially affects Linux users. The relevant details were disclosed in June 2024, but Intel and AMD found the problem independently. Intel fixed the issue in a microcode patch (INTEL-SA-00982) released in March, 2024. Nonetheless, some Intel hardware may not have received that microcode update. In their technical summary, Wikner and Razavi observe: "This microcode update was, however, not available in Ubuntu repositories at the time of writing this paper." It appears Ubuntu has subsequently dealt with the issue.
AMD issued its own advisory in November 2022, in security bulletin AMD-SB-1040. The firm notes that hypervisor and/or operating system vendors have work to do on their own mitigations. "Because AMD's issue was previously known and tracked under AMD-SB-1040, AMD considers the issue a software bug," the researchers explain. "We are currently working with the Linux kernel maintainers to merge our proposed software patch."
BleepingComputer adds that the ETH Zurich team "is working with Linux kernel maintainers to develop a patch for AMD processors, which will be available here when ready."
"We found a microcode bug in the recent Intel microarchitectures — like Golden Cove and Raptor Cove, found in the 12th, 13th and 14th generations of Intel Core processors, and the 5th and 6th generations of Xeon processors — which retains branch predictions such that they may still be used after IBPB should have invalidated them," explained Wikner. "Such post-barrier speculation allows an attacker to bypass security boundaries imposed by process contexts and virtual machines." Wikner and Razavi also managed to leak arbitrary kernel memory from an unprivileged process on AMD silicon built with its Zen 2 architecture.
Videos of the Intel and AMD attacks have been posted, with all the cinematic dynamism one might expect from command line interaction.
Intel chips — including Intel Core 12th, 13th, and 14th generation and Xeon 5th and 6th — may be vulnerable. On AMD Zen 1(+) and Zen 2 hardware, the issue potentially affects Linux users. The relevant details were disclosed in June 2024, but Intel and AMD found the problem independently. Intel fixed the issue in a microcode patch (INTEL-SA-00982) released in March, 2024. Nonetheless, some Intel hardware may not have received that microcode update. In their technical summary, Wikner and Razavi observe: "This microcode update was, however, not available in Ubuntu repositories at the time of writing this paper." It appears Ubuntu has subsequently dealt with the issue.
AMD issued its own advisory in November 2022, in security bulletin AMD-SB-1040. The firm notes that hypervisor and/or operating system vendors have work to do on their own mitigations. "Because AMD's issue was previously known and tracked under AMD-SB-1040, AMD considers the issue a software bug," the researchers explain. "We are currently working with the Linux kernel maintainers to merge our proposed software patch."
BleepingComputer adds that the ETH Zurich team "is working with Linux kernel maintainers to develop a patch for AMD processors, which will be available here when ready."
Is there even a "solution" as such? (Score:2)
Re:Is there even a "solution" as such? (Score:4, Informative)
There is. In some cases speculative execution must not be used. This is unfortunate, as kernel-entry almost universally qualifies and hence this will always come at a performance penalty. These days, I think the world will eventually move to microkernels and then containing such a problem becomes a lot easier.
Re: (Score:2)
These days, I think the world will eventually move to microkernels and then containing such a problem becomes a lot easier.
How do you figure?
In microkernels, the "kernel" memory boundary is universal- per process- even kernel process.
Do you perhaps mean hybrids like Darwin? (microkernels that have had all of the micro ripped out of them)
In a microkernel that focuses on some kind of MPI vs syscalls, the MPI interface still requires a syscall.
Re: (Score:2)
Side channels are incredibly hard to close, partly because they can be very very slow. Even leaking one bit per hour will put a massive massive dent into any cryptographic algorithms in short order.
One solution is to avoid superscalar, out of order architectures, which have speculative execution. Simpler architectures aren't vulnerable, but they are very very slow by comparison.
Re:And this is the reason why Win11 drops older pr (Score:4, Funny)
No. It is not. Stop pushing lies. Microsoft has never cared about security.
Re: (Score:2)
If Microsoft actively cared about security, the entire Windows OS would be completely refactored. Not on a code module level, but as a gestalt. For example, why are there multiple layers of app filtering, be it the AI based one to look for "sus" apps, Windows Defender, AppLocker, and whatever additional layers Microsoft throws on there.
Instead, Windows should go the route of something like Qubes OS, with containers for compatibility. The OS itself would be a hypervisor and a container layer, just like Wi
Re: (Score:2)
I agree with you, they do not care about security, what they do care about is partches, driver updates, and public image...
If a security fault makes them look bad, and they do not get patches and microcode update, they look even worse.
If an update to windows borks a SoC driver they look bad, and they do not get a new driver that fixes that, they look worse.
That's why they have to go with microprocessors/SoC where they are garanteed driver and microcode updates for the life of the OS (10 or 13 years dependin
6th-gen Xeons? (Score:2)
Does that include Granite Rapids? If so that's pretty bad. In fact most of Intel's datacentre AND consumer lineup will be affected. Only Lunar Lake would be immune at a hardware level, along with Arrow Lake once they launch it. Intel won't have a datacentre product for potentially another two years that doesn't require some sort of further mitigation, unless you count Clearwater Forest (which hopefully won't be affected).