Authors: Shauntinez Jakab, Michelle Netten
What you should know about Spectre Attacks
- Branch misprediction is the basis for the attack
- Attackers leverage the mis-training mechanism
- Process memory address space is affected
- Only works with data the application can access architecturally
- Four methods can be applied to mis-train branch prediction
What you should know about Meltdown
- Exploits faults triggered with retiring faulting instructions
- Reliant upon unauthorized out-of-order transient instructions following execution
- Transient instructions work with data inaccessible to the application
- Only possible with faults, not exceptions, traps or aborts.
This unique class of threats continues to brew
Spectre and Meltdown continued to simmer throughout much of 2018. Initial noise erupted a year ago with an announcement disclosing attack variants that can leverage known chip-level flaws in processors by leading chip makers. While the hype slowed some and no major attacks (on vulnerable systems) have yet been reported, at least 20 attack variations have since been documented by experts. Organizations would be naïve to think hackers aren’t busily working on ways to exploit these largely indefensible threats.
Spectre and Meltdown represent the rare appearance of an entirely unique class of vulnerabilities, affecting transient execution in most modern computer processing chips and the devices that use them. Intel, AMD, and ARM chips, and even Power8 and 9 from IBM, all are affected, some of them less than others. A processor that is vulnerable to one is not necessarily vulnerable the other, so it’s recommended to check the vendor. Currently, we are not aware of all possible variants, nor do we understand the full scope of their implications. Existing defenses remain partially effective, as they fail to address the root of the problem and in the most efficient manner.
Figure 1: Universal transient execution attack classification tree with demonstrated attacks (red, bold), negative results (green, dashed), some first explored in this work (. / . ). Source: A Systematic Evaluation of Transient Execution Attacks and Defenses
Twenty variants and counting
In the meantime, we’re left to manage the risks we’re all exposed to. Throughout 2018, it became clear that the Spectre/Meltdown problem is steadfastly growing. In addition to earlier reported attack types (see our blog on SpectreRSB https://virsec.com/spectre-rears-its-ugly-head-with-spectrersb/), fourth quarter 2018 brought seven new attack variants (as listed below), discovered as experts reassessed the Spectre and Meltdown vulnerability classification to uncover the full “residual attack surface” – see List 1 below. Of the new exploit methods, two attacks were against flaws in meltdown memory protection keys and bound instructions. The remaining variants effect Spectre mis-training strategies for branch prediction.
Below is a brief summary of the new attacks types and which vendor processors are at risk.
Seven of the newest Spectre and Meltdown attacks*
1. Meltdown-PK (Protection Key Bypass)—On Intel CPUs, an attacker with code execution ability in the containing process can bypass both read and write isolation guarantees enforced through memory-protection keys for userspace. In contrast to cross-privilege level Meltdown attack variants, there is no software workaround. Intel can only fix Meltdown-PK in new hardware or possibly via a microcode update.
2. Meltdown-BR (Bounds Check Bypass)—Intel and AMD x86 processors that ship with Memory Protection eXtensions (MPX) or IA32 bound for efficient array bounds checking can be bypassed to encode out-of-bounds secrets that are never architecturally visible. Meltdown-BR attack exploits transient execution following a #BR exception to encode out-of-bounds secrets that are never architecturally visible. Meltdown-BR is an exception driven alternative for Spectre-PHT (Spectre-PHT (Pattern History Table). Proofs-of-concept demonstrate out-of-bounds leakage through a Flush+Reload covert channel for an array index safeguarded by either IA32 bound (Intel, AMD), or state-of-the-art MPX protection (Intel-only).
3. Spectre-PHT-CA-OP (Cross-Address-space Out of Place)— Performing previously disclosed Spectre-PHT attacks within an attacker-controlled address space at a congruent address to the victim branch. On Intel, the primary microarchitectural element exploited is the Pattern History Table (PHT). Depending on predictor mode, it is accessed based on combination of some bits from branch instruction virtual address and shift registers which contain the information about the last N branches, with N depending on the architecture. The PHT contains a biasing bit indicating whether a branch is mostly taken or not.
4. Spectre-PHT-SA-IP (Same Address-space In Place)—Performing Spectre-PHT attacks within the same address space and the same branch location that is later on exploited. All Spectre-PHT attacks presented so far, are same-address-space in-place attacks. On Intel, the primary microarchitectural element exploited here is the Pattern History Table (PHT). The PHT contains a biasing bit indicating whether a branch is mostly taken or not.
5. Spectre-PHT-SA-OP(Same Address-space Out of Place)—Performing Spectre-PHT attacks within the same address space with a different branch. Spectre-BTB (Branch Target Buffer)
6. Spectre-BTB-SA-IP (Same Address-space In Place)—Performing Spectre-BTB attacks within the same address space and the same branch location that is later on exploited.
7. Spectre-BTB-SA-OP (Same Address-space Out of Place)—Performing Spectre-BTB attacks within the same address space with a different branch.
*Swati K, “ 7 New Meltdown and Spectre-type CPU Flaws Affect Intel, AMD, ARM CPUs” The Hacker News, 11/14/18
The attack range is much broader than first suspected. The new variants, as with the earlier discovered vulnerabilities, enable attacks on the execution of transient instructions in new ways. Researchers found there to be not one, but four strategies for branch misprediction attacks. In recent studies* we see that attackers are no longer limited to observing state changes at the micro-level and leveraging information in CPU cache. Attackers can leverage any observable or variable microarchitectural state, like covert side-channels, thus enabling attacks on cryptographic algorithms, user input and kernel addressing information.
Organizations are challenged with common defenses
Some have taken the time to evaluate all the defenses out there against attacks like these. Individual specialized tools and vendor patches do not cover all attack types, and in some cases, patches and hardware changes have yet to come.
With Spectre attacks, taint tracking, site isolation and timer reduction have been thought to provide acceptable coverage against all known variants. But each has drawbacks that can compromise security and data. Taint tracking, a feature in some programming languages such as Perl and Ruby, is designed to prevent malicious users from executing commands on the host. It’s believed to be the most effective of all; however, it ignores implicit information flows, thus affecting accuracy in detection. This is a substantial disadvantage when it comes to security. Site isolation is helpful for partial mitigation, but data leakage persists within the same process and is therefore not a full solution. Timer accuracy reductions only slow the efforts of attackers in getting to the information, as it too can be circumvented.
Table: Defense categories
Is patching the panacea?
Because Spectre and Meltdown are a CPU-based set of vulnerabilities, they are different from other types of flaw that organizations must defend against. No single patch exists that will fix these two. It takes a combination of "micro-code" patches from CPU vendors, plus operating system patches. These are more difficult. Intel provides guidelines on the process for its updates (https://www.intel.com/content/dam/www/public/us/en/documents/sa00115-microcode-update-guidance.pdf)
Applying patches and staying up to date is important. But it’s not a panacea and for many organizations, it’s not even possible.
Relying on patching is a flawed strategy
Industrial control facilities are notoriously not up to date on patching, for many justifiable reasons, including that their systems cannot be brought down for any length of time. This leaves them vulnerable. Attacks that leveraged the EternalBlue vector successfully exploited a vulnerability of the SMBv1 code in Windows 7 and Windows Server 2008, both of which were released a decade ago, as well as Windows XP from even farther back.
The extent of the damage caused demonstrates that these versions of older operating systems still have a large deployed footprint. WannaCry and other attacks prove the point above, that even when vendors like Microsoft have a patch available, enterprises and especially ICS systems, don’t or can’t always deploy it in time—or at all—to protect themselves.
Retpoline defense
Other defenses like Retpoline offer protection for a single type of attack. The infamous Retpoline seems to be effective in mitigating Spectre attacks (variant 2) targeting the Branch Target Buffer across various vendors, but you will need something else for RSB, BTB or STL type of attacks. WebKit’s poison value prevents Spectre-PHT-based attacks, whereas indexing is only a partial solution for the same. RSB stuffing proved to be a reasonable approach against Spectre-RSB from different processes. Otherwise, attackers can circumvent it.
Known defenses focus on impeding specific attacks, mainly targeting cache, branch target buffer. Defenses greatly lack sufficient consideration for the full microarchitectural level, especially around ensuring secret data can’t be reached and maintain operational integrity against new attack types. This means that future attacks methods are always on the horizon.
Defenses that work – Only Virsec has you covered
Virsec offers a different kind of solution that protects the full application surface with security that is far more effective and precise than any existing WAF or RASP security solution. (See below for WAF and RASP limitations.)
Virtual patching without source code
As pointed about above, for many reasons, many industrial control systems aren’t up to date on patching. Virsec provides unique protection to any application, regardless of being behind on patches or support releases. Virsec never requires access to source code as it provides this protection. This effective control for industrial control systems and SCADA security compensates for out-of-date patches and enables any application to run safely, even on vulnerable platforms.
Conventional security comes up short
- Web Application Firewalls (WAFs) are notoriously difficult to manage, don’t understand applications and deliver floods of false positives
- Next Gen WAFs take a similar approach closer to the app but only deliver marginally better results
- Runtime Application Self Protection (RASP) solutions are intrusive, impractical and often require code changes – non-starters for most SecOps teams
Summary of Virsec defense against Spectre and Meltdown attacks
Organizations that have deployed Virsec Security Platform for additional application defense, are uniquely protected against Spectre exploits, without changes to hardware, software, kernel or microcode. Its Trusted Execution™ technology preemptively patches vulnerabilities at the binary level to minimize risk and prevent advanced memory-based threats, fileless malware, and unknown or zero-day attacks in real time.
The technology employs a deterministic approach to threat detection and automates protection, preventing efforts to tap into application memory and leak data, or misdirect functions and application process flows. It essentially renders all Spectre variants useless at first attempt, including SpectreRSB. Additionally, customers also benefit from protection against cartographic operations on kernel memory commonly associated with Meltdown.
Virsec offers much needed relief to organizations concerned about preventing Spectre exploits. –– unburdening IT from patching microcode flaws and ensuring a strong defense against future business crippling Spectre variants without an urgency to upgrade systems.
Learn more about protecting against memory-based threats
Sources:
- A Systematic Evaluation of Transient Execution Attacks and Defenses
- Meltdown & Spectre Vulnerabilities
For more information, please visit these resources:
White paper: Protecting Applications from Speculative Execution Vulnerabilities Exposed by Spectre and Meltdown
Article: Complete Spectre and Meltdown defense
