Two Hard-to-Detect Spectre Flaws Found for Intel, Arm Processors

Two researchers, Vladimir Kiriansky and Carl Waldspurger, uncovered two more Spectre flaws in Intel’s processors. Both flaws, Spectre 1.1 and Spectre 1.2, affect Intel and Arm processors, and they may affect AMD CPUs, too.

Spectre 1.1

The first flaw the researchers uncovered is a variant of the original Spectre v1 (first variant) speculative execution flaw found in most modern processors earlier this year. Spectre 1.1 leverages speculative stores to create speculative buffer overflows, which can modify data and code pointers. This type of attack can also bypass existing Spectre 1.0 mitigations either directly or by redirecting control flow.

Intel and Arm have already come out and acknowledged that their processors are vulnerable to Spectre 1.1. AMD hasn’t released a statement yet, but chances are this also affects AMD’s CPUs.

Spectre 1.2

According to the researchers, Spectre 1.2 is similar to Spectre v3 in the sense that it depends on bypassing lazy read/write protections. Attacks that exploit the Spectre 1.2 flaw can overwrite read-only data, code pointers, and code metadata, including control flow mitigation metadata. As a result of this, hardware-enforced sandboxing protection is rendered ineffective.

The researchers have validated the Spectre 1.2 attack on both Intel and Arm processors. They also suggested that a hardware fix would ideally check the the translation lookaside buffer (TLB) entries to confirm write privileges.

Chance of Mitigation Is Low

The researchers noted in their paper that currently no effective static analysis or compiler instrumentation can even detect or mitigate Spectre 1.1. They also added that Spectre v1 mitigations can stop only subset of the possible attacks against that flaw.

The researchers said:

“If we must rely on software mitigations that require developers to manually reason about the necessity of mitigations, we may face decades of speculative-execution attacks. The limited success at educating software developers for the past thirty years since the 1988 public demonstration of classic buffer overflows is a cautionary guide.

The silver lining is that the same coding patterns are vulnerable to speculative buffer overflows. A good first step toward preventing them would be to strengthen existing checks against stack overflows, heap overflows, integer overflows, etc.“

What the researchers are actually implying is first that software mitigations largely depend on app developers to implement them, which means that most applications won’t be protected, if history is any guide; second, hardware changes will be necessary for true long-term fixes that can stop Spectre flaws from appearing.