This article is more than 1 year old
Intel chip flaw: Math unit may spill crypto secrets from apps to malware
Nasties on Cores, Xeons may lift computations, mitigations in place or coming
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. For example, Intel's AES encryption and decryption instructions use FPU registers to hold keys.
In short, the security hole could be used to extract or guess at secret encryption keys within other programs, in certain circumstances, according to people familiar with the engineering mishap.
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 allowed to peek at.
The fix is to employ a mechanism called eager FPU state restore. 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:
This issue, known as Lazy FP state restore, is similar to Variant 3a. It has already been addressed for many years by operating system and hypervisor software used in many client and data center products. Our industry partners are working on software updates to address this issue for the remaining impacted environments and we expect these updates to be available in the coming weeks.
We continue to believe in coordinated disclosure and we are thankful to Julian Stecklina from Amazon Germany, Thomas Prescher from Cyberus Technology GmbH, Zdenek Sojka from SYSGO AG, and Colin Percival for reporting this issue to us. We strongly encourage others in the industry to adhere to coordinated disclosure as well.
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. RHEL 5, 6, and 7, and Enterprise MRG 2 not running kernel-alt are vulnerable. In a statement to The Register, the Linux vendor clarified that this a potential task-to-task theft of information:
Red Hat has been made aware of an issue where operating systems and virtual machines running on common modern (x86) microprocessors may elect to use “lazy restore” for floating point state when context switching between application processes instead of “eagerly” saving and restoring this state.
Exploitation of lazy floating point restore could allow an attacker to obtain information about the activity of other applications, including encryption operations. The underlying vulnerability affects CPU speculative execution similar to other recent side channel vulnerabilities.
In this latest vulnerability, one process is able to read the floating point registers of other processes being lazily restored. Red Hat’s mitigations are in various stages of availability via software (kernel) patches and configuration changes as described below.
Mitigations will not require microcode updates. In most cases, Red Hat Enterprise Linux 7 customers will not need to take action, while other users may need to apply software updates.
"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. One of the research outfits named above, Cyberus, has an advisory and background, here.
It was believed modern Microsoft Windows releases were immune to this bug: they are not, so get patching.
Additional reporting by Shaun Nichols.