Red Hat is aware of a microarchitectural (hardware) implementation issue that could allow an unprivileged local attacker to bypass conventional system security controls to allow read-only access to kernel memory. This is similar to previous speculative execution attacks released earlier for microprocessors.
At this time, this specific flaw is known to only affect Intel-based processors. This flaw is hardware-based and no additional mitigation, beyond those already released for previous microarchitectural side channel attacks, are currently planned to be released.
Based on current information, Red Hat does not currently believe this flaw poses a significant additional risk. The requirements for exploitation are exceedingly difficult to achieve outside of specifically contrived lab examples, and existing mitigations also raise the bar against this vector.
Technical Details and Background
A flaw was found in CPU microarchitecture structures similar to previous Microarchitectural Data Sampling (MDS) vulnerabilities that impact Intel microprocessors. This flaw allows for attacker-controlled values to be injected into impacted microarchitectural structures so that they can be used to steer subsequent speculative execution of victim code.
By using this mechanism, an attacker can target private data structures in other processes and extract them while the code is being executed on the target CPU. This new attack method can theoretically function even when existing speculative execution side-channel vulnerability mitigations are in effect, although current knowledge has not shown any feasible attack vector outside of lab conditions.
For this exploit to work correctly, the victim code must provide gadgets that are capable of being abused similar to the Spectre V1 gadgets from previous speculative execution flaws. This attack also requires that when the victim loads the attacker-controlled value, the load must trigger a fault or an assist. An assist can occur whenever a page table Accessed or Dirty (A or D) bit needs to be updated. The assist creates a speculation window for the victim gadgets to leak the data. There are currently no known reliable ways for users to manipulate the victim into triggering an assist, however, although future techniques may determine a way to make this possible.
Attack vector, User Land Process to Kernel
Existing Spectre V1 mitigations greatly reduce the ability of a process to attack kernel data structures. CPUs which implement Supervisor Mode Access Prevention (SMAP) also mitigate this attack vector. If new, simpler attack vectors are identified, kernel changes may be required to further mitigate these issues, although at this time no additional change is believed to be needed.
Attack vector, User Land Process to Process
An attacker attempting to force a fault/assist on a target process must exploit a narrow window of opportunity and the target must also contain gadgets which can be exploited using this alternative method.
Attack vector, Guest to Host
This attack is very complex and involves the coordination of numerous difficult steps and preconditions, including the injection of attacker-controlled data into microarchitectural buffers shortly before forcing a fault/assist on a target process which then executes a multi-step gadget.
Attack vector, Guest to Guest
This attack vector is similar to the process-to-process vector described above, except that this vector is expected to be even more difficult and impractical due to the increased isolation between guests. At this time there are no known exploits capable of launching an attack in this manner.
For hardware vulnerable to these attacks, there is no known hardware mitigation other than to upgrade to hardware that is not vulnerable to this flaw.
Due to the high level of difficulty of the attack, and the performance impact which would be associated with any potential mitigations, there are currently no microcode or software mitigations for this issue other than previously existing Spectre V1 and SMAP mitigations described above.
Red Hat doesn't currently have knowledge of any real-world occurrences of this attack, so the risk of attack may be considered low. To further minimize the possibility of attacks related to this and other speculative issues, trusted and untrusted workloads can be isolated on separate systems.
For further details about potential mitigations, see Intel's LVI deep dive whitepaper.
Frequently Asked Questions
Q: How can I determine if my system is affected ?
A: Consult the list of affected CPU’s below:
- 6th Generation Intel® CoreTM Processor Family
- 7th Generation Intel® CoreTM Processor Family
- 8th Generation Intel® CoreTM Processor Family
- 9th Generation Intel® CoreTM Processor Family
10th Generation Intel® CoreTM Processor Family
Intel® Xeon® Processor E3 v5 Family
- Intel® Xeon® Processor E3 v6 Family
- Intel® Xeon® Processor E-2100 Family
- Intel® Xeon® Processor E-2200 Family
Q: Intel's technical information on this flaw makes a lot of references to SGX, why is that not covered here?
A: At this time, no software shipped by Red Hat supports SGX.
Red Hat thanks Intel and industry partners for reporting this issue.