With speculative execution attacks remaining a stubbornly persistent vulnerability ailing modern processors, new research has highlighted an "industry failure" to adopt mitigations released by AMD and Intel, posing a firmware supply chain threat.
Dubbed FirmwareBleed by Binarly, the information leaking assaults stem from the continued exposure of microarchitectural attack surfaces on the part of enterprise vendors either as a result of not correctly incorporating the fixes or only using them partially.
"The impact of such attacks is focused on disclosing the content from privileged memory (including protected by virtualization technologies) to obtain sensitive data from processes running on the same processor (CPU)," the firmware protection firm said in a report shared with The Hacker News.
"Cloud environments can have a greater impact when a physical server can be shared by multiple users or legal entities."
In recent years, implementations of speculative execution, an optimization technique that predicts the outcome and target of branch instructions in a program's execution pipeline, have been deemed susceptible to Spectre-like attacks on processor architectures, potentially enabling a threat actor to leak cryptographic keys and other secrets.
This works by tricking the CPU into executing an instruction that accesses sensitive data in memory that would normally be off-limits to an unprivileged application and then extracting the data after the operation is undone following a misprediction.
A key countermeasure to prevent the harmful effects of speculative execution is a software defense known as retpoline (aka "Return Trampoline"), which was introduced in 2018.
Although recent findings such as Retbleed have conclusively shown that retpoline by itself is insufficient against stopping such attacks in certain scenarios, the latest analysis shows a lack of consistency in even applying these mitigations in the first place.
"Our FirmwareBleed research shows that industry adoption can be quite low and mitigations do not always apply even if they are technically available," Alex Matrosov, CEO and co-founder of Binarly, told The Hacker News.
Specifically, it takes aim at a best practice called Return Stack Buffer (RSB) stuffing introduced by Intel to avoid underflows when using retpoline. RSBs are address predictors for return (aka RET) instructions.
"Certain processors may use branch predictors other than the Return Stack Buffer (RSB) when the RSB underflows," Intel notes in its documentation. "This might impact software using the retpoline mitigation strategy on such processors."
"On processors with different empty RSB behavior, [System Management Mode] code should stuff the RSB with CALL instructions before returning from SMM to avoid interfering with non-SMM usage of the retpoline technique."
Intel is also recommending RSB stuffing as a mechanism to thwart buffer underflow attacks like Retbleed, alternatively urging vendors to "set [Indirect Branch Restricted Speculation] before RET instructions at risk of underflow due to deep call stacks."
The Binarly research, however, has identified as many as 32 firmware from HP, 59 from Dell, and 248 from Lenovo as having not included the RSB stuffing patches, underscoring a "failure in the firmware supply chain."
"Since the same technique with LFENCE is used for mitigation, a Retbleed attack can technically bypass RSB mitigation at the firmware level as well," Matrosov pointed out.
"The Retbleed vulnerable code primitives must be present in the firmware code for the attack to succeed. Intel and AMD have already addressed Retbleed fixes to mitigate the attack, but the main problem is how quickly the industry will adopt them."
What's more, the deep code analysis has unearthed instances wherein a mitigation was present in the firmware, but it contained implementation mistakes that spawned security issues of its own, even in updates released in 2022 and for devices featuring the recent generation of hardware.
"Firmware supply chain ecosystems are quite complex and often contain repeatable failures when it comes to applying new industry-wide mitigations or fixing reference code vulnerabilities," the researchers said. "Even if a mitigation is present in the firmware, it doesn't mean it is applied correctly without creating security holes."
