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:
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
“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.
Lucian Armasu is a Contributing Writer for Tom's Hardware US. He covers software news and the issues surrounding privacy and security.
-
stdragon So...the flaw isn't HW, but rather a fundamental philosophy in computing within the relm of computer science. NICE! *slow clap*Reply
You can't fix what hasn't been implemented. -
DerekA_C I like how they say it may affect AMD just to try and throw crap at AMD's major successes in the last year. Something tells me I doubt AMD is affect. Intel kept doing the same thing over and over and it is now biting them in the butt.Reply -
Christopher1 I have said it before and I will say it again: SANDBOX SANDBOX SANDBOX! Sandboxing would prevent or mitigate a lot of these attacks.Reply -
stdragon Sandboxing wouldn't do squat. In fact, these Spectre exploits hit cloud based hosting providers hard. That's because running malicious code in one VM that exploits this can snoop the RAM of the underlying physical host and gain access to the contents of another VM.Reply
Basically, speculative execution, and hyper threading by extension is fundamentally flawed. In fact, OpenBSD now disables HT all together. No more beating around the bush. -
Christopher1 The problem with getting rid of 'speculative execution' is that it is part of what makes computers today so fast: Information is 'kept in memory' and when the processor needs it? It just pulls it out of memory if it is needed within a reasonable amount of time.Reply
If we have to go back to "Program uses memory and then all data is flushed!" expect computers to get much much slower.
One person on PCWorld was talking about a 50% decrease in computing speed. -
stdragon Intel stated across the board integer performance loss anywhere from 2% to 8% after patching Spectre v4 with microcode. Meaning, it's irregardless if the process is in kernel or user land. However, Coffee Lake CPUs (8th gen) are currently seeing anywhere from 1% to 3% hit.Reply
I'm not sure if Intel's numbers are on average against all the Core series with the oldest being the worst, or just pre-Haswell where INVPCID for PCID (Process Context ID) isn't available.