Security

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.

Modern versions of Linux – from kernel version 4.9, released in 2016, and later – as well as the latest spins of OpenBSD 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 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.

Amazon Web Services said it is protected. Intel's advisory is also now live, here.

"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.

Final update

It was believed modern Microsoft Windows releases were immune to this bug: they are not, so get patching.

Additional reporting by Shaun Nichols.

Send us news
67 Comments

Intel scores a reprieve in $2.18B VLSI patent case after court orders retrial

The never-ending IP story goes on

German budget woes threaten chip fab funding for Intel and TSMC

Constitutional court tells govt: Er, about that €60B you handed out... it's not legal

China's Loongson debuts processor that 'matches Intel silicon circa 2020'

Best not to dismiss it, as Asus looks to be onboard and advances are promised

Greenpeace calls out tech giants for carbon footprint fumble

Net-zero promises or zero-net progress?

Washington pours $3B into silicon smackdown to outpackage Asia

Uncle Sam rolls up sleeves to onshore work and protect supply chain

Intel emits patch to squash chip bug that lets any guest VM crash host servers

Sapphire Rapids, Alder Lake, Raptor Lake chip families treated for 'Redundant Prefix'

Intel chips away at carbon footprint but skims over thirst for water, chemicals

Semiconductors are a dirty business

Aurora dawns late: Half-baked entry secures second in supercomputer stakes

Half the machine, quadruple the anticipation for all-Intel super

Intel drops the deets on UK's Dawn AI supercomputer

Phase one packs 512 Xeons, 1,024 Ponte Vecchio GPUs. Phase two: 10x that

Downfall fallout: Intel knew AVX chips were insecure and did nothing, lawsuit claims

Billions of data-leaking processors sold despite warnings and patch just made them slower, punters complain

Intel's Arun Gupta on open source pragmatism and fanatics

VP of the Open Ecosystem at chip biz talks trust in the era of AI

Intel to build hush-hush fabs to bake chips for US military

'Secure enclave' reports point to separate production line with blocked off access