Linux kernel developers are fixing up a trio of weaknesses in the open-source project – after a Google engineer reported that defenses implemented to stop speculative-execution snooping do not work as intended.
In three posts marked urgent to the Linux kernel mailing list on Tuesday, Anthony Steinhauser points out problems with countermeasures put in place to block Spectre vulnerabilities in modern Intel and AMD x86 microprocessors that perform speculative execution.
The Spectre family of flaws involve making a target system speculate – perform an operation it may not need – in order to expose confidential data so an attacker can obtain it through an unprotected side channel. It is typically exploited by malware already running on a computer, or a rogue user already logged in.
There's an optimization to Speculative Store Bypass Disable (SSBD), a defense against the Speculative Store Bypass vulnerability (CVE-2018-3639), that was put in place to avoid an expensive model-specific register (MSR) write operation. But the optimization turns out to be a liability because an eavesdropper could use it to disable SSBD.
Steinhauser says there's a logic flaw that sets the wrong value for enforcing SSBD.
"It is exploitable if the attacker creates a process which enforces SSBD and has the contrary value of STIBP (Single Threaded Indirect Branch Predictors) than the victim process … and schedules it on the same core as the victim process," he explained.
"If the victim runs after the attacker the victim becomes vulnerable to Spectre V4."
Linux will also force-disable a Spectre mitigation called Indirect Branch Prediction Barrier (IBPB) – a defense against Branch Target Buffer attacks from Spectre V2 – in certain situations, specifically when STIBP is not available or when Indirect Branch Restricted Speculation (IBRS) is available.
This could make AMD-powered computers running Linux vulnerable since the manufacturer advises [PDF] using IBPB rather than IBRS or STIBP to defend against Spectre V2.
Finally, Steinhauser points out that settings for disabling indirect branch speculation don't work.
"Currently, it is possible to enable indirect branch speculation even after it was force-disabled using the
PR_SPEC_FORCE_DISABLE option," he wrote. Moreover, the
PR_GET_SPECULATION_CTRL command gives afterwards an incorrect result (force-disabled when it is in fact enabled)."
The corrected code is now working its way into the Linux code-base, and should be available shortly. ®
Sponsored: Webcast: Simplify data protection on AWS