The return of Spectre
Video: Intel's patches for Spectre variant 4 will slow your CPU
Meltdown-Spectre
The return of Spectre sounds like the next James Bond movie, but it's really the discovery of two new Spectre-style CPU attacks.
Vladimir Kiriansky, a Ph.D. candidate at MIT, and independent researcher Carl Waldspurger found the latest two security holes. They have since published a MIT paper, Speculative Buffer Overflows: Attacks and Defenses, which go over these bugs in great detail. Together, these problems are called "speculative execution side-channel attacks."
These discoveries can't really come as a surprise. Spectre and Meltdown are a new class of security holes. They're deeply embedded in the fundamental design of recent generations of processors. To go faster, modern chips use a combination of pipelining, out-of-order execution, branch prediction, and speculative execution to run the next branch of a program before it's called on. This way, no time is wasted if your application goes down that path. Unfortunately, Spectre and Meltdown has shown the chip makers' implementations used to maximize performance have fundamental security flaws.
Read also: Meltdown-Spectre: Malware is already being tested by attackers
Since the initial Spectre and Meltdown discoveries, there has been many other Spectre-style holes found. In their latest research, Kiriansky and Waldspurger have discovered two new security problems: Spectre 1.1 and Spectre 1.2.
Spectre 1.1 uses speculative data stores to create speculative buffer overflows. Much like classic buffer overflows attacks, speculative out-of-bounds stores can change data and code pointers. Worse still, such attacks can bypass some original Spectre mitigations, either directly or by redirecting control flow. Control-flow attacks enable arbitrary speculative code execution, which can, in turn, bypass other software mitigations for previous speculative-execution attacks. Adding insult to injury, the researchers report, "It is easy to construct return-oriented-programming (ROP) gadgets that can be used to build alternative attack payloads."
Spectre 1.2 can foul up CPUs that do not enforce read/write protections. With this, speculative stores can overwrite read-only data and code pointers to breach sandboxes. With this ability, an attacker can own a machine.
Intel has thanked Kiriansky and Waldspurger for reporting the new vulnerabilities to the chip maker. The company has paid Kiriansky $100,000 via its HackerOne bug bounty program.
So, what can you do about these attacks? Get ready to do a lot of reprogramming.
This won't' be easy. The researchers state that there are no programming tools, such as static analysis or compiler instrumentation, which generically detect or mitigate Spectre 1.1.
Indeed, "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."
Read also: Spectre and Meltdown: Cheat sheet - TechRepublic
They're not optimistic. After all, the very first computer worm, the infamous Morris worm, is 30 years old and used a buffer overflow to knock out much of the early internet. Today, we still see buffer overflow security holes showing up in programs.
Still, "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." We may still be far from perfect from mitigating buffer overflows, but at least we know how we should fix them.
Intel adds, "These two methods of attack can be mitigated by modifying software through the insertion of a serializing instruction to constrain speculation in confused deputies. Such instructions ensure that all instructions in the processor's instruction pipeline up to the speculation barrier resolve before any later instructions in the pipeline can execute. This prevents the processor from speculatively accessing data that the user should not have access to, because no speculative operations can run until the bounds check operation completes."
In short, you'll get a slower program, since this method blocks all speculative operations, but you'll be much more secure.
ARM states, the "majority of ARM processors are not impacted by any variation of this side-channel speculation mechanism." That said, "this method is dependent on malware running locally which means it's imperative for users to practice good security hygiene by keeping their software up-to-date and avoid suspicious links or downloads."
On July 13, AMD finally commented: "This week, a sub-variant of the original, Google Project (GPZ) variant 1 / Spectre security vulnerability was disclosed by MIT. Consistent with variant 1, we believe this threat can be mitigated through the operating system (OS). AMD is working with the software ecosystem to mitigate variant 1.1 through operating system updates where necessary. We have not identified any AMD x86 products susceptible to the Variant 1.2 vulnerability in our analysis to-date. Please check with your OS provider for the latest information."
Read also: Spectre and Meltdown: Details you need on those big chip flaws - CNET
AMD hasn't said yet which, if any, of its chips are vulnerable and what you should do about it if they are vulnerable.
The operating system companies are also on the ball. "Microsoft has released updates to help mitigate these vulnerabilities. To get all available protections, firmware (microcode) and software updates are required. This may include microcode from device OEMs and in some cases updates to AV software as well. In some cases, installing these updates will have a performance impact. We have also taken action to secure our cloud services."
Windows won't be the only operating system to see a performance hit. All operating systems will see slowdowns. How much? We don't know yet.
Red Hat reports speculative execution side-channel attacks impact the Linux kernel used in Red Hat Enterprise Linux (RHEL) 5, 6, and 7. This suggests that nearly all modern Linux distributions are vulnerable. The Linux kernel developers are already working on upstream patches for the problem.
When the patches and microcode are out, update your systems. If your company makes software, comb through your code for vulnerabilities to these new holes and patch them. For now, there are no known attacks using these bugs. That won't be true for long.
Related stories: