Another day, another Intel CPU security hole: Lazy State
Once upon a time, when we worried about security, we worried about our software. These days, it’s our hardware, our CPUs, with problems like Meltdown and Spectre, which are out to get us. The latest Intel revelation, Lazy FP state restore, can theoretically pull data from your programs, including encryption software, from your computer regardless of your operating system.
Like its forebears, this is a speculative execution vulnerability. In an interview, Red Hat Computer Architect Jon Masters explained: “It affects Intel designs similar to variant 3-a of the previous stuff, but it’s NOT Meltdown.” Still, “It allows the floating point registers to be leaked from another process, but alas that means the same registers as used for crypto, etc.” Lazy State does not affect AMD processors.
This vulnerability exists because modern CPUs include many registers (internal memory) that represent the state of each running application. Saving and restoring this state when switching from one application to another takes time. As a performance optimization, this may be done “lazily” (i.e., when needed) and that is where the problem hides.
This vulnerability exploits “lazy state restore” by allowing an attacker to obtain information about the activity of other applications, including encryption operations. Thus, systems using Intel Core-based microprocessors, from Sandy Bridge on to today’s newest processors, may allow a local process to infer data using lazy floating point state restore from another process through a speculative-execution side channel. So, in this latest vulnerability, one process can read the floating point registers of other processes being lazily restored.
For some operating systems, the fix is already in. Red Hat Enterprise Linux (RHEL) 7 automatically defaults to (safe) “eager” floating point restore on all recent x86-64 microprocessors (approximately 2012 and later) implementing the “XSAVEOPT” extension. Therefore, most RHEL 7 users won’t need to take any corrective action.
Other operating systems believed to be safe are any Linux version using the 2016’s Linux 4.9 or newer kernel. The Linux kernel developers are patching older kernels. Most versions of Windows, including Server 2016 and Windows 10. are believed to be safe. If you’re still using Windows Server 2008, however, you will need a patch. The latest editions of OpenBSD and DragonflyBSD are immune, and there’s a fix available for FreeBSD.
The good news, according to Masters: “Impact is moderate because while it’s important to address, it’s hard to exploit and easy to fix.”
Better still, Masters said, “the fix will improve performance!”
Unlike the previous CPU security bugs, mitigating it will not require microcode updates. In most cases, RHEL 7 customers will not need to take action. RHEL 5 and 6 users will need to patch their servers.
This security problem was found by Julian Stecklina from Amazon Germany, Thomas Prescher from Cyberus Technology, and Zdenek Sojka from SYSGO AG.
So, while not a serious problem, it is a real one. If your system isn’t immune, patch it as soon as possible.
Related Stories:
READ MORE HERE