Updated A security flaw within Intel Core and Xeon processors can be potentially exploited to swipe sensitive data from the chips’ math processing units.
Malware or malicious logged-in users can attempt to leverage this design blunder to steal the inputs and results of computations performed in private by other software.
These numbers, held in FPU registers, could potentially be used to discern parts of cryptographic keys being used to secure data in the system. In short, the security hole could be used to extract or guess at private encryption keys within other programs, in certain circumstances, according to people familiar with the engineering mishap.
Modern versions of Linux – from kernel version 4.9, released in 2016, and later – and modern Windows, including Server 2016, as well as the latest spins of OpenSD and DragonflyBSD are not affected by this flaw (CVE-2018-3665).
Windows Server 2008 is among the operating systems that will need to be patched, we understand, and fixes for affected Microsoft and non-Microsoft kernels are on their way. The Linux kernel team is back-porting mitigations to pre-4.9 kernels.
Essentially, hold tight, and wait for patches to land for your Intel-powered machines, if they are vulnerable. CVE-2018-3665 isn’t the end of the world: malicious software has to be already running on your system to attempt to exploit it, and even then, it can only lift out crumbs at a time.
It is yet another complex, speculative-execution-related processor design flaw that is fascinating for industry watchers, an annoyance for some kernel programmers, and another thing for sysadmins and folks to patch for. There are worse bugs, a whole lot worse, in your word processor, PDF reader, or web browser, probably.
The brown exploit jumps over the lazy coprocessor
The security shortcoming involves what’s known as lazy FPU state restore. Operating system kernels would only save and restore the floating-point unit (FPU) registers, and other context information, when programs were actually using the math unit.
This, it turned out today, through a security gaffe in Intel’s blueprints related to Spectre-Meltdown Variant 3A, allows a program to obtain scraps of the FPU context of another app. Variant 3A allows applications to read system registers that only privileged code should be to peek at.
The fix is to employ a mechanism called eager FPU state restore, which modern Linux, Windows and other kernels use. These mitigations do not carry a performance hit – in fact, eager state switching can increase performance.
Intel is due to release an advisory with more details after 2pm PT (2100 UTC). It had planned to go live on June 27, however disclosure was brought forward to today after the OpenBSD and DragonflyBSD projects earlier this week published their patches to mitigate this issue – thus forcing the situation onto the world stage. The BSD teams went ahead after Intel declined to work with them under embargo, and instead stuck to larger operating system vendors and makers.
A spokesperson for the American semiconductor giant told The Register today that it was alerted to the flaw by various researchers working independently, including one at Amazon:
Intel considers the threat to be moderate. Google told us its systems are secured against this lazy FPU state restore cockup. Spokespeople for Amazon and Microsoft were not available for comment. ®
Updated to add
Red Hat has more technical details, here. In a statement to The Register, the Linux vendor clarified that this a potential task-to-task theft of information:
“System software may opt to utilize Lazy FP state restore instead of eager save and restore of the state upon a context switch,” the x86 goliath explained.
“Lazy restored states are potentially vulnerable to exploits where one process may infer register values of other processes through a speculative execution side channel that infers their value.”
There is, right now, no known exploit code circulating in the wild targeting this security vulnerability, we’re told.
Additional reporting by Shaun Nichols.