Tag Archives: CPU

Responding to the Intel Spoiler Vulnerability

====================
Updated: 20th March 2019
====================
TL DR:
The Intel Spoiler vulnerability is not as bad as predicted. Software developers should continue to use safer code development practices.

====================
After the disclosure earlier this month of this vulnerability Intel have provided further information on how it affects their microprocessors. They have clarified that the Spoiler exploit by itself does not reveal secret data and is not a speculative execution side channel method:

Other good news is that existing mitigations such as KPTI (kernel page table isolation) reduce the risk of leaking data across privilege levels. They again confirmed that side channel safe software development practices such as “ensuring execution time and control flows are identical regardless of secret data” will mitigate classic side channel methods enabled by the Spoiler exploit. Furthermore, they confirmed memory modules which are already mitigated against Rowhammer attacks remain protected against the Spoiler exploit.

Lastly AMD provided formal confirmation that their microprocessors are not vulnerable after preliminary findings suggested they weren’t vulnerable. AMD’s statement is available from this link.

Thank you.

====================
Original Post:
====================
Earlier this month a new vulnerability was disclosed in a research paper titled “Spoiler: Speculative load hazards boost Rowhammer and cache attacks”.

TL DR: Mitigating this newly disclosed vulnerability is the job of software developers to work around using safer code development practices. Mitigating this issue in hardware will take longer since current measures cause too much of a performance penalty.

Why should this vulnerability be considered important?
Using this new method; attackers are likely to find existing cache and memory Rowhammer attacks easier to carry out. In addition, JavaScript (defined) attacks which can take long periods of time may be shortened to mere seconds. The paper contains a cache prime and probe technique to leak sensitive data using JavaScript.

This Spoiler vulnerability can be used by attackers (who MUST have already compromised your system) to extract sensitive information from the systems memory (RAM). An attack does not require elevated privileges.

What CPUs (microprocessors / computer chips) are affected?
This vulnerability affects Intel processors only; first generation Intel Core (from early 2006) and later are affected. ARM and AMD processors are not affected. Any system with an Intel Core processor is affected regardless of the operating they are using namely Linux, Unix, Apple macOS and Windows can be all affected.

How does this vulnerability achieve the above results?
The security researchers who authored the paper found a vulnerability in the memory order buffer that can be used to gradually reveal information about the mappings of physical memory to non-privileged software processes (in other words; applications). This technique also affects virtual machine (VM) and sandboxed (defined) environments.

The technique works by understanding the relationship between virtual and physical memory by timing the speculative load and store operations to these areas while looking out for discrepancies which disclose the memory layout to you. With this information an attacker knows where to focus their efforts.

Intel’s proprietary implementation of the memory subsystem (memory disambiguation) is the root cause of the vulnerability. When a physical address conflict (the address/area is already in use) occurs, the algorithm leaks the access timings. The algorithm in the researcher’s words works as follows “Our algorithm, fills up the store buffer within the processors with addresses that have the same offset but they are in different virtual pages. Then, we issue a memory load that has the same offset similarly but from a different memory page and measure the time of the load. By iterating over a good number of virtual pages, the timing reveals information about the dependency resolution failures in multiple stages.”

How can this vulnerability be mitigated/patched?
This vulnerability lies within the memory disambiguation algorithm which won’t be trivial to resolve anytime soon. Since this vulnerability is not related to last years Spectre vulnerability; mitigations for that vulnerability don’t help here. Current Spoiler mitigations have too much of performance penalty. At this time, Intel has issued the following statement:

“Intel received notice of this research, and we expect that software can be protected against such issues by employing side channel safe development practices. This includes avoiding control flows that are dependent on the data of interest. We likewise expect that DRAM modules mitigated against Rowhammer style attacks remain protected. Protecting our customers and their data continues to be a critical priority for us and we appreciate the efforts of the security community for their ongoing research.”

The side channel safe development practices are linked to below:

Software Guidance for Security Advisories

Addressing Hardware Vulnerabilities

Thank you.

PortSmash Vulnerability: What you need to know

Security researchers have released details of a new side channel attack known as “PortSmash” that can be used to steal information from processes running inside a computer systems CPU (defined)) when Intel Hyperthreading (HT)(defined here and here) is enabled. Their proof of concept allowed them to steal a private decryption from a thread running in the same core as their exploit. This thread belonged to an OpenSSL process.

How severe is this vulnerability?
It has been designated as CVE-2018-5407 and assigned a base score of 4.8 (medium severity) on the CVSS v3 scale (defined) with a high attack complexity and with only low privileges required. The attack cannot be exploited remotely. An attacker must have been able to compromise your system via another means most likely a phishing email (social engineering)(phishing: defined; social engineering: defined), accidentally clicking a malicious link or a drive by download (defined). The attacker will also still need to have their code running within the same core as the data/code they wish to obtain. Similar to Spectre; multi-tenant cloud environments are more at risk.

Red Hat’s security advisory states “In order to exploit this flaw, the attacker needs to run a malicious process on the same core of the processor as the victim process”. PortSmash is fundamentally different from Meltdown and Spectre vulnerabilities; it does not rely on speculative execution.

Collin Percival, a Computer Scientist summed up the attack as follows:

“I’ve been getting a few questions about the recent “PortSmash” vulnerability announcement. Short answer: This is not something you need to worry about. If your code is vulnerable to it, you were already vulnerable to other (easier) attacks.

He advises that users don’t need to worry about it and states: “the defence against microarchitectural side channel attacks from 2005: Make sure that the cryptographic key you’re using does not affect the sequence of instructions or memory accesses performed by your code”.

How does this vulnerability work?
When a thread (defined) is carrying out some work it has its own instructions (what to do) and data (the objects to work on) but it will share some of its hardware resources with another process operating on a collocated thread.

The attackers can obtain information about the decryption key by analysing how fast the (process) thread within the CPU is operating with particular assembly language (defined) instructions and uses that information to work backwards (reverse engineering) on what possible data was used as the input to achieve this data now being processed. In this case the data is a private decryption key (defined).

Explained another way: This attack uses instruction timing (how long it takes to process) based on port contention. Each core of a CPU has physical regions known as ports which carry out the necessary calculations. If two or more threads are processing at the same they may have to wait on each other to use those regions of the CPU.

PortSmash seeks to monopolise a port which is being shared with a thread with information the attack wishes to obtain. They can measure the time taken between instructions of the attackers thread and the legitimate thread (thus determining how long the legitimate thread spend processing). This will help to obtain the data being processed over a long period of time

PortSmash is a side channel attack meaning that the attacker doesn’t immediately find out the protected/secret value immediately; instead the attack seeks out information from the other thread running within the CPU for information on the secret value being processed.

The proof of concept code targeted OpenSSL but is not limited to just that software. OpenSSL was targeted due to the researcher’s familiarity with the OpenSSL code.

What CPUs are affected by this vulnerability?
The researchers verified that this vulnerability is present on Intel Skylake CPUs (6th generation Core models e.g. i7 6700K). However any Intel CPU which implements HT is likely to have this vulnerability. Intel’s Nehalem architecture first introduced HT in 2008. The researchers believe AMD Ryzen CPUs may be affected but did not confirm this.

How can I protect myself from this vulnerability?
OpenSSL have added a fix to version 1.1.1 and older versions greater than version 1.1.0i (Source)

However the only true means of mitigating this vulnerability for all software is to disable Intel’s HT. The operating system distribution OpenBSD has done so since June this year. Similarly Intel within their new 9th generation Core CPUs disabled HT to enable hardware protections against the Meltdown, Spectre and L1 Terminal Fault vulnerabilities. They did so to their gaming focused CPUs since many games don’t leverage HT and thus don’t suffer a performance penalty from not using it. It doesn’t appear that HT was removed for security concerns since the Core i9 9900K still features it.

Since corporate organizations may have invested in software that uses HT; they should only consider turning it off if continuing to use it places them at a high risk of exploitation and would place them outside of what they consider an acceptable risk. They will then need to consider the performance/security trade-off of doing so.

If you use Intel HT I would recommend testing your own software with this feature turned off to tell if it has too much of a performance penalty for your particular use cases. From researching this it is not a straightforward answer of turning it off and definitely not experiencing any slowdown; it may or may not happen depending on how you use your system and the software you use.

I have provided links to definitions of HT above and some references below which may assist you in making a decision to disable or leave it enabled. That research also pointed out that if you wish to disable HT; please do so from the BIOS (defined) of your computing system since it will have a blanket disablement across all software and your operating system. A software disablement can work but disabling via the BIOS leaves less room for error. Please refer to your system manufacturer or motherboard user guide for the steps to enter the BIOS of the system and disable this feature.

As more details of this vulnerability emerge I will consider disabling this feature on my water cooled Intel Core i9 7980XE CPU. Windows detects it with 36 logical cores; with HT disabled it will “drop” to 18 physical cores. I’ll need to evaluate the performance impact (if any) for my particular use cases. Given the attacker will need to already have compromised my system and the attack is of high complexity; it’s less likely I will need to disable HT. My existing security controls are more than enough to mitigate this risk; but your system, configuration and risk appetite may be different.

Thank you.

==============

References:

Why You Disable Hyper-Threading or NOT, and How to Know the Difference

https://bitsum.com/tips-and-tweaks/why-you-should-not-disable-hyper-threading-or-why-you-should/

Nehalem – Everything You Need to Know about Intel’s New Architecture

Source: https://www.anandtech.com/show/2594/8

 

Performance-impact of Hyper-Threading:

https://superuser.com/questions/1166529/performance-impact-of-hyper-threading

 

Is Hyper-Threading a Fundamental Security Risk?

https://www.extremetech.com/computing/276138-is-hyper-threading-a-fundamental-security-risk

Why does disabling hyperthreading supposedly give better gaming performance? (This is again a gaming focused discussion but would be relevant for software that does not use HT):

https://www.reddit.com/r/pcgaming/comments/2hti6m/why_does_disabling_hyperthreading_supposedly_give/

 

Why on earth would you disable Hyperthreading? (This is a more gaming focused discussion but would be relevant for software that does not use HT. Please ignore the advert spam posts for software named CPUCores, it’s confirmedsnake oil”):

https://steamcommunity.com/app/384300/discussions/0/530646080862961117/

==============

Vendors Respond to Foreshadow (L1TF) Vulnerabilities

Yesterday, academic and security researchers publically disclosed (defined) 3 new vulnerabilities affecting Intel CPUs (AMD and ARM are not affected).

What are these new vulnerabilities and what can they allow an attacker to do?
The first vulnerability known as Foreshadow or CVE-2018-3615 is used to extract data from an Intel SGX (Software Guard Extensions)(defined) secure enclave (area) by creating a shadow copy of the SGX protected data but that copy does not have the protection of SGX and can be read/accessed by the attacker. The attacker can also re-direct speculative execution into copying further private/sensitive into the shadow copied area while at the same time making it appear that area is genuine and thus has the same protection as the real SGX protected data.

The second vulnerability (part of a wider Foreshadow Next Generation (NG) group of two variants) known as CVE-2018-3620 allows the reading of data copied into the level 1 cache (defined) of a CPU (defined) when that data is in use by a computer operating system e.g. Red Hat Linux, Apple macOS or Microsoft Windows.

The third vulnerability is the second and final variant of the Foreshadow NG group known as CVE-2018-3646.  This affects virtualised environments. If a CPU thread (defined) being directed by an attacker is able to read the level 1 cache of a CPU that is also shared by another thread by a victim user (within another virtualised environment but using the same physical CPU) while that request will be blocked; if the information the attacker is looking to steal is in the level 1 cache they may still get a glimpse of this information.

How can I protect myself from these new vulnerabilities?
For the first and second vulnerabilities; the microcode (defined)/firmware (defined) updates made available earlier this year coupled with the newly released updates for operating systems linked to below will mitigate these two issues.

====================

For the third vulnerability; affecting virtualised (defined) environments there are operating system updates and microcode/firmware updates available that will occasionally clear the contents of the level 1 cache meaning that when the attacker attempts to read it they will not receive any benefit from doing so. Partially removing the usefulness of the cache will have a performance impact from a few percent up to 15 percent in the worst case scenario.

However to completely mitigate this third vulnerability a capability known as Core Scheduling needs to be leveraged. This ensures that only trusted/non attacker controlled virtual machines have access to the same thread (this capability is already available in some virtual machine (hypervisor)(defined) environments).

However in some environments if it cannot be guaranteed that all virtual machines are trustworthy the disabling of Intel Hyper Threading (this means that only 1 thread will work per CPU core)(otherwise known as simultaneous multi-threading (SMT)(defined)) may be necessary and will more significantly impact performance than just the level 1 cache clearing.

In summary for this third vulnerability; depending upon the virtualised environment you are using and the trustworthiness of the virtual machines you are using will determine how many of the these extra security measure you will need to take.

To be clear I am NOT advocating that Intel Hyper Threading/SMT be disabled EN MASSE for security reasons. As per the advice in the linked to advisories (below)(specifically Intel and VMware) ; you MAY wish to disable Intel Hyper Threading/SMT to mitigate the third vulnerability (CVE-2018-3646) depending upon the environment your virtualised machines are operating.

This Ars Technica article explains it very well: “if two virtual machines share a physical core, then the virtual machine using one logical core can potentially spy on the virtual machine using the other logical core. One option here is to disable hyperthreading on virtual-machine hosts. The other alternative is to ensure that virtual machines are bound to physical cores such that they don’t share.”

====================

Please find below links to vendor responses on these vulnerabilities as well as videos that can help in understanding these vulnerabilities:

Thank you.

====================

Foreshadow Vulnerability Official Website:
https://foreshadowattack.eu/

Intel’s Blog Post:
https://newsroom.intel.com/editorials/protecting-our-customers-through-lifecycle-security-threats/

Intel’s FAQ Page:
https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf.html

Intel’s Security Advisory:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html

Intel’s Software Developer Guidance:
https://software.intel.com/security-software-guidance/software-guidance/l1-terminal-fault

Red Hat’s Security Advisory:
https://access.redhat.com/security/vulnerabilities/L1TF

Linux Kernel Patch:
https://lore.kernel.org/patchwork/patch/974303/

Oracle’s Security Advisory:
https://blogs.oracle.com/oraclesecurity/intel-l1tf

Amazon Web Services’ Security Advisory:
https://aws.amazon.com/security/security-bulletins/AWS-2018-019/

Google Cloud Security’s Blog Post:
https://cloud.google.com/blog/products/gcp/protecting-against-the-new-l1tf-speculative-vulnerabilities

Microsoft Windows Azure’s Guidance:
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/mitigate-se

Microsoft’s Windows Security Advisory (high level details):
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180018

Microsoft’s Technical Analysis of the Foreshadow Vulnerabilities:
https://blogs.technet.microsoft.com/srd/2018/08/10/analysis-and-mitigation-of-l1-terminal-fault-l1tf/

VMware Security Advisories:
https://www.vmware.com/security/advisories/VMSA-2018-0020.html

https://www.vmware.com/security/advisories/VMSA-2018-0021.html
====================

Videos:
Foreshadow Video (explains the first vulnerability very well):
https://www.youtube.com/watch?v=ynB1inl4G3c

Intel’s Video (explains all 3 vulnerabilities):
https://www.youtube.com/watch?v=n_pa2AisRUs

Demonstration of the Foreshadow attack:
https://www.youtube.com/watch?v=8ZF6kX6z7pM

Red Hat’s Video (explains all 3 vulnerabilities):
https://www.youtube.com/watch?v=kBOsVt0iXE4

Red Hat’s In-depth video of the 3 vulnerabilities:
https://www.youtube.com/watch?v=kqg8_KH2OIQ

====================

August 2018 Update Summary

Today Microsoft released updates to resolve 63 vulnerabilities (more formally known as CVEs (defined)).

This month also brings a new set of vulnerabilities affecting only Intel CPUs. I detail these more thoroughly in a separate post. However high level details are provided below.

Compared to previous months updates these have a smaller list of known issues (most of which have workarounds). Links to the relevant knowledge base (KB) articles are provided below:

KB4340731

KB4340733

KB4343885

KB4343892

KB4343897

KB4343900

KB4343909

====================

Adobe also released update for the following products:

Adobe Acrobat and Reader DC (priority 2, 2x CVEs)

Adobe Creative Cloud Desktop (priority 3, 1x CVE)

Adobe Experience Manager (priority 2, 3x CVEs)

Adobe Flash (priority 2, 5x CVEs)

As always if you use any of the above Adobe software, please update it as soon as possible especially in the case of Flash and Acrobat DC/Reader DC. Updates for Google Chrome will be available shortly either via a browser update or their component updater.

Please also review the out of band updates for Photoshop CC and Creative Cloud Desktop and apply them if you use these products.

You can monitor the availability of security updates for most your software from the following websites (among others) or use one of the utilities presented on this page:
—————
US Computer Emergency Readiness Team (CERT) (please see the “Information on Security Updates” heading of the “Protecting Your PC” page):

https://www.us-cert.gov/

A further useful source of update related information is the Calendar of Updates. News/announcements of updates in the categories of General SoftwareSecurity Software and Utilities are available on their website. The news/announcements are very timely and (almost always) contain useful direct download links as well as the changes/improvements made by those updates (where possible).

If you like and use it, please also consider supporting that entirely volunteer run website by donating.

====================
For this month’s Microsoft updates, I will prioritize the order of installation below:

====================

Microsoft Edge and Internet Explorer (multiple versions of Edge and IE affected)

Windows Font Library

Malicious LNK File

Microsoft Exchange

Foreshadow (L1TF) Vulnerabilities: Allow information disclosure via speculative execution; are only locally executable (rather than remotely). This vulnerability may allow one virtual machine to improperly access information from another. More details in my dedicated blog post.

====================
Please install the remaining updates at your earliest convenience.

As usual; I would recommend backing up the data on any device for which you are installing updates to prevent data loss in the rare event that any update causes unexpected issues. I have provided further details of updates available for other commonly used applications below.

Please find below summaries of other notable updates released this month.

Thank you.

=======================
Nvidia Geforce Experience Software:
=======================
In late August, Nvidia released a security advisory for their Geforce Experience software for Windows. This update resolves 3 high severity vulnerabilities (as per their CVSS base scores). The necessary updates can be obtained from here.

=======================
VideoLAN VLC:
=======================
On the final day of August, VideoLAN made available VLC 3.0.4. This appears to be a security update for Apple macOS due to the following entries within the releases notes (however it is unclear if this overflow is exploitable by an attacker):

=======================
Text renderer:
* Fix head buffer overflow on macOS with some fonts
=======================

For Linux and Windows this version provides fixes numerous non-security issues. Please update to version 3.0.4 to benefit from these improvements.

=======================
Wireshark 2.4.9 and 2.6.3
=======================
v2.4.9: 3 security advisories

v2.6.3: 3 security advisories

As per standard process Linux distributions can obtain this update using the operating systems standard package manager (if the latest version is not installed automatically using the package manager you can instead compile the source code (v2.6.3) or v2.4.9). This forum thread and this forum thread may also be helpful to you with installing Wireshark on your Linux based system.

For Mac OS X and Windows, the update is available within the downloads section of the Wireshark website. In addition, a detailed FAQ for Wireshark is available here.

=======================
WinSCP:
=======================
In late August; WinSCP version 5.13.1 was released upgrading it’s embedded OpenSSL version to 1.0.2p (which addresses 2x low severity CVEs (Link1 and Link2).

=======================
OpenSSL
=======================
On the 12 June and 16th April 2018; the OpenSSL Foundation issued 2 updates for OpenSSL to address 2x low severity security vulnerabilities as detailed in these security advisories (Link1 and Link2). To resolve these issues please update your OpenSSL installations to 1.1.0i (released 14th August) or 1.0.2o (released 14th August) (as appropriate).

FTP mirrors to obtain the necessary downloads are available from here.

Downloadable Tarballs (compressed/packaged code made for distribution) are available from here.

It should also be possible to use the package manager of a Linux/Unix operating system to update your OpenSSL installation as mentioned within the section titled “Installing updates for Linux distributions” on the “Protecting Your PC” page of this blog.

=======================
VMware
=======================
VMWare issued two security advisories for the following products during August:

Security advisory 1 (addresses 1 vulnerability of Important severity):

  • VMware Horizon 6
  • VMware Horizon 7
  • VMware Horizon Client for Windows
  • VMware Horizon View Agent
  • VMware Horizon Agents Installer (HAI)

Security advisory 2 (addresses 1 vulnerability of Critical severity):

  • VMware Workstation Pro / Player (Workstation)
  • VMware Fusion Pro, Fusion (Fusion)

If you use the above VMware products, please review the security advisories and apply the necessary updates.

SpectreRSB and NetSpectre Vulnerabilities Explained

In late July; security researchers publicly disclosed (defined) a new set of vulnerabilities within Intel CPUs (defined) (and possibly AMD and ARM; which the researchers also notified). These vulnerabilities are collectively referred to as SpectreRSB (Return Stack Buffer). The purpose of an RSB is explained in this document (PDF) but in summary it is a buffer (defined) that stores multiple return addresses while attempting to predict function (a set of instructions that carries out a specific action within a program) return addresses.

A very short time later nearing the end of July; a separate set of researchers released details of another vulnerability known as NetSpectre. This is an evict and reload cache attack that targets systems remotely to extract data.

How could an attacker exploit these vulnerabilities and what is the result?
For SpectreRSB; an attacker could recover data from the speculative execution feature of the CPU by targeting the Return Stack Buffer and predicting the return address which it stores. By manipulating the data it contains by predicting the return address the CPU will access when it completes a task the attacker can influence the address CPU will jump to and thus jump to an address of the attacker’s choosing. Unfortunately; this buffer is shared among the threads (defined) on the same virtual process thus affecting multiple running processes and virtual machines.

The attacker could alter the RSB to expose and gather data from applications running within the CPU. Another form of manipulation by the researchers resulted in them being able to expose data contained within Intel’s Software Guard Extensions (defined)(PDF).

====================

Separately for the NetSpectre vulnerability; if attackers can send specifically crafted packets (defined) to a vulnerable system they can use the responses they receive to infer data from that systems memory. Currently this can only take place at a very low rate; 15 bits per hour. This means 15 times a zero or a one; in other words true or false (I’m not referring to Boolean logic here; just trying to convey a concept) or even simpler on for 1 and off for zero. This increased to 60 bits per hour for an Intel CPU equipped with AVX2 instructions.

With such a low throughput at this time (although I realise an attack can usually be refined and significantly improved within a short time); this attack is not a practical threat but more a theoretical weakness.

How can I protect myself from these vulnerabilities?
The good news for this SpectreRSB subclass of vulnerabilities is that Intel has already created an update but not for all of it’s CPU (Intel Core i7 Skylake (6th Generation Core models) and later CPUs). The researchers are aware of this patch and are recommending it’s use. When I use the word subclass above; my meaning is that SpectreRSB is a subclass of the original Spectre vulnerabilities from January this year. Red Hat also announced they are reviewing these vulnerabilities.

Intel however have stated that existing mitigations from the vulnerabilities disclosed in January will protect against this new subclass. However this is unconfirmed at this time.

====================

While an APT (defined) could leverage the NetSpectre vulnerability over a period of weeks or months to extract useful data; existing mitigations for Spectre variant 1 and variant 2 mitigate this new vulnerability reinforcing my statement above of being a theoretical weakness.

In summary; to protect against both classes of these vulnerabilities; please continue to roll-out the mitigations for the Spectre vulnerabilities from January 2018 (if you have not already completed them).

For any system which cannot be updated (due to performance or end of life constraints e.g. Intel not providing updates for some CPUs); seek to migrate the responsibilities/roles/duties of these systems to newer CPUs which have received updates. A list of patched and un-patched Intel CPUs is available here (PDF).

Thank you.

Intel Lazy Floating Point Vulnerability: What you need to know

====================
Update: 24th July 2018:
====================
I have updated the list of vendor responses below to include further Red Hat versions and CentOS:

Red Hat Enterprise Linux 6:
https://access.redhat.com/errata/RHSA-2018:2164

Red Hat Enterprise Linux 5 and 7:
https://access.redhat.com/solutions/3485131

CentOS 6:
https://lists.centos.org/pipermail/centos-announce/2018-July/022968.html

CentOS 7:
https://lists.centos.org/pipermail/centos-announce/2018-June/022923.html

====================

On Wednesday of last week, a further vulnerability affecting Intel CPUs (defined) was disclosed.

TL;DR: Keep your operating system up to date and you should be fine.

What makes this vulnerability noteworthy?
According to Intel’s security advisory; this is an information disclosure issue. Similar to Spectre/Meltdown the flaw is the result of a performance optimization (used when saving and restoring the current state of applications as a system switches from one application to another). A feature known as Lazy Floating Point (defined) Unit (FPU) is used to save and restore registers (defined) within the CPU used to store floating point numbers (non-integers numbers, namely decimal numbers).

The issue is that these registers may be accessed by another application on the same system. If the registers are storing for example results of performing cryptographic equations for a key you have just created or used to decrypt data, the attacker could use this data to infer what the actual key is. The same applies for any type of data the registers store; that data can be used to infer what the previous contents were via a speculative execution side channel.

This vulnerability has been rated as moderate since it is difficult to exploit via a web browser (in contrast to Spectre) and the updates will be a software update only; no microcode (defined) and/or firmware (defined) updates will be necessary. With exploitation via a web browser being difficult; this vulnerability will likely instead be exploited from the victim system (at attacker will need to have already compromised your system).

How can I protect myself from this vulnerability?
Please note; AMD CPUs are NOT affected by this vulnerability.

The following vendors have responded to this vulnerability with software updates now in progress. Separately Red Hat has completed their updates for Red Hat Linux 5, 6 and 7 (with further applicable updates still in progress).

Other vendors responses are listed below. Thank you:

Amazon Web Services

Apple (currently release notes for an update to macOS to resolve the vulnerability)

DragonFlyBSD

Intel’s Security Advisory

Linux

Microsoft Windows

OpenBSD

Xen Project