“Speculative Execution, Variant 4: Speculative Store Bypass”
Jann Horn, Monorail, Project Zero, February 6, 2018
“Side-Channel Vulnerability Variants 3a and 4”
United States Computer Emergency Readiness Team, May 22, 2018
“Spectre Chip Security Vulnerability Strikes Again; Patches Incoming”
Steven J. Vaughn-Nichols, Zero Day, May 22, 2018
At least eight new variants of the Spectre vulnerability have been discovered and will be surfacing soon. One was discovered by Google's Project Zero team, which notoriously publishes the vulnerabilities they discover after ninety days, regardless of whether patches have been found. For that one, time's up on Monday, May 7.
Some of the vulnerabilities are more consequential or more easily exploited than others. One is reported to cause a serious problem for host systems running virtual machines: Malware running on a VM can break into the host or into other VMs on the same host.
“Exclusive: Spectre-NG — Multiple New Intel CPU Flaws Revealed, Several Serious”
Jürgen Schmidt, c't, May 3, 2018
One of the Spectre-NG flaws simplifies attacks across system boundaries to such an extent that we estimate the threat potential to be significantly higher than with Spectre. Specifically, an attacker could launch exploit code in a virtual machine (VM) and attack the host system from there — the server of a cloud hoster, for example. Alternatively, it could attack the VMs of other customers running on the same server. Passwords and secret keys for secure data transmission are highly sought-after targets on cloud systems and are acutely endangered by this gap. Intel's Software Guard Extensions (SGX), which are designed to protect sensitive data on cloud servers, are also not Spectre-safe.
Although attacks on other VMs or the host system were already possible in principle with Spectre, the real-world implementation required so much prior knowledge that it was extremely difficult. However, the aforementioned Spectre-NG vulnerability can be exploited quite easily for attacks across system boundaries, elevating the threat potential to a new level. Cloud service providers such as Amazon or Cloudflare and, of course, their customers are particularly affected.
Researchers have discovered another vulnerability in the Spectre family. Like Spectre, it exposes side effects of speculative execution of instructions. Whereas Spectre extracted the information from the cache, the new attack, called BranchScope, extracts it from the directional predictor, which is the component of the branch-prediction unit inside the processor.
The directional predictor is updated each time a conditional branch instruction is executed, even speculatively, and maintains an estimate of the likelihood that the condition will be true the next time the same conditional branch instruction is executed. It leaks information because its state is modified during speculative execution and not restored afterward if the speculative execution path turns out not to have been the correct one.
“BranchScope: A New Side-Channel Attack on Directional Branch Predictor”
Dmitry Evtyushkin, Ryan Riley, Nael Abu-Ghazaleh, and Dmitry Ponomarev, Proceedings of the 23rd ACM International Conference on Architectural Support for Programming Languages and Operating Systems, March 24, 2018
“As Predicted, More Branch Prediction Processor Attacks Are Discovered”
Peter Bright, Ars Technica, March 26, 2018
Last month, Microsoft announced an improvement in their compiler for Visual C and C++. It now blocks some variants of the Spectre attack by inserting
LFENCE instructions to block speculative execution when it detects a pattern in the code it is compiling that is characteristic of Spectre attacks. In effect, the compiler is using the antivirus technique of looking for a "signature" of the attack and applying countermeasures when it finds one.
This approach has two main limitations. Firstly, blacklisting known attacks instead of whitelisting code patterns that are known to be safe, doesn't address the vulnerability in full generality, since an unanticipated variant of the attack that has a slightly different signature can still succeed. Secondly, it complicates debugging and maintenance, since it is much more difficult to identify, by manual inspection, cases in which the countermeasures should have been applied but weren't than to find (operationally) cases in which the countermeasures were applied even though they weren't needed.
Microsoft chose the signature-blacklisting approach because it entails less of a performance penalty: Programs compiled with the new compiler run almost as fast as the vulnerable versions produced by the old compiler. If it had been designed to insert
LFENCE instructions whenever it could not prove that the code being compiled was safe without them, the performance hit would have been much, much larger.
“Spectre Mitigations in Microsoft's C/C++ Compiler”
Paul Kocher, February 13, 2018
The author of this article created a rough benchmark to determine how much protection the signature-blacklisting approach actually provides. He took the proof-of-concept C program provided by the team that devised the Spectre attack in the first place and developed fourteen variations of the key function. Most of the variations were easy and straightforward, not to say trivial.
Microsoft's new C compiler correctly inserted
LFENCE instructions in the original proof-of-concept code and in one of the variants (in which the key instruction was replaced with a call to a function that executed the instruction and the function was then inlined). The new C compiler generated unsafe code for the other thirteen variants.
For decades now, lazy programmers have relied on ever-faster processors and ever-larger memories to avoid learning about subtle but efficient algorithms and fast data structures with intricate invariants. Now the jig is up.
“Death Notice: Moore's Law. 19 April 1965 — 2 January 2018”
Mark Pesce, The Register, January 24, 2018
The computer science behind microprocessor design has therefore found itself making a rapid U-turn as it learns that its optimization techniques can be weaponized. The huge costs and Meltdown and Spectre — which no one can even guess at today — will make chip designers much more conservative in their performance innovations, as they pause to wonder if every one of those innovations could, at some future point, lead to the kind of chaos that has engulfed us all over the last weeks.
One thing has already become clear: in the short term, performance will go backwards. The steady … improvements every software engineer could rely on to make messy code performant can no longer be guaranteed. …
Going forward, the game changes from “cheaper and faster” to “sleeker and wiser.” Software optimizations — despite their Spectre-like risks — will take the lead over the next decades. …
From here on in, we're going to have to work for it.
Early attempts to patch operating systems and processor microcode in order to block Meltdown attacks and impede some known instances of the Spectre strategy have had adverse results (beyond slower performance, which was anticipated): incompatibility with some third-party anti-virus utilities, driver crashes, bricking of some AMD systems, and processor crashes on Intel systems that still use the Haswell and Broadwell designs.
Meanwhile, researchers are making progress in turning the proof-of-concept implementations described in the original papers on Meltdown and Spectre into practical attacks.
“Spectre and Meltdown Patches Causing Trouble As Realistic Attacks Get Closer”
Peter Bright, Ars Technica, January 15, 2018
This is all a mess. Some companies, such as cloud service providers, have no real option but to install all the updates, including the microcode updates, because their vulnerability is so great; their business is running untrusted third-party code. For the rest of us, there is urgency, but that needs to be balanced against reliability.
That urgency is growing each day, however, particularly when it comes to the Meltdown attack.
“Speculation Considered Harmful?”
“Nemo”, Cryptography mailing list, January 16, 2018
Even if you eliminate speculative execution entirely, the cache still holds “footprints” of the execution of your privileged code. And it is hard to prove exactly what information that conveys (or does not convey).
There are two kinds of security. One is where you say “I do not see how an attacker can do X.” The other is where you say “I can prove the attacker cannot do X, assuming Y and Z.” The former leaves you vulnerable to people smarter and/or more motivated than you. The latter is what you want.
Cache timing attacks, given the implicit management of the cache by the CPU hardware, means that I do not know exactly what information I am leaking from privileged code no matter how I write that code.
And it is not just the cache. Consider performance counters, debug registers, register renaming (i.e. vastly more physical registers than architectural registers), etc. All of this implicitly-managed state might carry who-knows-what information across protection domains. …
To prove that nothing interesting passes across protection domains, given all those megabytes of implicitly managed state … is going to require some serious rethinking of CPU architecture.