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.

Similar topics


Other stories you might like

  • India reveals home-grown server that won't worry the leading edge

    And a National Blockchain Strategy that calls for gov to host BaaS

    India's government has revealed a home-grown server design that is unlikely to threaten the pacesetters of high tech, but (it hopes) will attract domestic buyers and manufacturers and help to kickstart the nation's hardware industry.

    The "Rudra" design is a two-socket server that can run Intel's Cascade Lake Xeons. The machines are offered in 1U or 2U form factors, each at half-width. A pair of GPUs can be equipped, as can DDR4 RAM.

    Cascade Lake emerged in 2019 and has since been superseded by the Ice Lake architecture launched in April 2021. Indian authorities know Rudra is off the pace, and said a new design capable of supporting four GPUs is already in the works with a reveal planned for June 2022.

    Continue reading
  • Prisons transcribe private phone calls with inmates using speech-to-text AI

    Plus: A drug designed by machine learning algorithms to treat liver disease reaches human clinical trials and more

    In brief Prisons around the US are installing AI speech-to-text models to automatically transcribe conversations with inmates during their phone calls.

    A series of contracts and emails from eight different states revealed how Verus, an AI application developed by LEO Technologies and based on a speech-to-text system offered by Amazon, was used to eavesdrop on prisoners’ phone calls.

    In a sales pitch, LEO’s CEO James Sexton told officials working for a jail in Cook County, Illinois, that one of its customers in Calhoun County, Alabama, uses the software to protect prisons from getting sued, according to an investigation by the Thomson Reuters Foundation.

    Continue reading
  • Battlefield 2042: Please don't be the death knell of the franchise, please don't be the death knell of the franchise

    Another terrible launch, but DICE is already working on improvements

    The RPG Greetings, traveller, and welcome back to The Register Plays Games, our monthly gaming column. Since the last edition on New World, we hit level cap and the "endgame". Around this time, item duping exploits became rife and every attempt Amazon Games made to fix it just broke something else. The post-level 60 "watermark" system for gear drops is also infuriating and tedious, but not something we were able to address in the column. So bear these things in mind if you were ever tempted. On that note, it's time to look at another newly released shit show – Battlefield 2042.

    I wanted to love Battlefield 2042, I really did. After the bum note of the first-person shooter (FPS) franchise's return to Second World War theatres with Battlefield V (2018), I stupidly assumed the next entry from EA-owned Swedish developer DICE would be a return to form. I was wrong.

    The multiplayer military FPS market is dominated by two forces: Activision's Call of Duty (COD) series and EA's Battlefield. Fans of each franchise are loyal to the point of zealotry with little crossover between player bases. Here's where I stand: COD jumped the shark with Modern Warfare 2 in 2009. It's flip-flopped from WW2 to present-day combat and back again, tried sci-fi, and even the Battle Royale trend with the free-to-play Call of Duty: Warzone (2020), which has been thoroughly ruined by hackers and developer inaction.

    Continue reading

Biting the hand that feeds IT © 1998–2021