Analysis You've patched your Intel, AMD, Power, and Arm gear to crush those pesky data-leaking speculative execution processor bugs, right? Good, because IBM eggheads in Switzerland have teamed up with Northeastern University boffins in the US to cook up Spectre exploit code they've dubbed SplitSpectre.

SplitSpectre is a proof-of-concept built from Speculator, the team's automated CPU bug-discovery tool, which the group plans to release as open-source software. Their work is described here in an academic paper emitted earlier this week.

Andrea Mambretti, told The Register that he and his Speculator coauthors – Engin Kirda, William Robertson of Northeastern University and IBM's Matthias Neugschwandtner, Alessandro Sorniotti, and Anil Kurmus – aren't trying to scare the world with yet more chip vulnerability exploits, but rather want to prise open the secrets of CPU microarchitecture.

The big silicon design houses keep details of the inner mechanisms of their processors under tight wraps, which means discovering speculative execution flaws and suchlike requires a non-trivial amount of reverse-engineering.

Thus, Speculator tries to automate that discovery process. Spec-ex is one of the key drivers of processor speed, which is why CPU engineers and their bosses don't like to talk about it, in case they spill any secrets to competitors.

Mambertti explained to The Register Speculator came about from “the analysis of common elements of [speculative execution] attacks," and should "help the analysis of new and old attacks.

“SplitSpectre is the result of our analysis, and thanks to Speculator, we could precisely measure the characteristics required for an attack to succeed as well as study general behaviors of the CPU during speculation that before were not known or documented.”

SplitSpectre: If you patched, relax

Speculator was able to find a “novel variation" in the techniques needed to exploit Spectre variant 1 vulnerabilities in processors. These are those flaws you've heard so much about, the ones that can be abused by dodgy applications and malware to leak passwords, crypto-keys, secrets, and other data from the computer's memory that should be off-limits.

This particular variation was dubbed SplitSpectre, and it differs from previous exploits by “requiring a smaller piece of vulnerable code available in the victim’s attack surface.” Spectre exploitation relies on specific sequences of code running in the software you're trying to spy on. SplitSpectre requires a shorter chain of instructions in its victim, which means code thought to be invulnerable to Spectre may actually be snooped on by this new technique.

Having said that, today's mitigations for Spectre should thwart this version of SplitSpectre. Future versions may be more successful, or "viable," as the researchers put it. It is a proof-of-concept of Speculator, after all, and is written in JavaScript to run in Mozilla's SpiderMonkey JS engine.

One key point is that SplitSpectre can snoop on the underlying JavaScript engine, meaning it could in theory peek at private and sensitive data used by other JavaScript code running at the same time on the engine, say, in other tabs within a browser.

One defense mechanism is to, therefore, securely sandbox browser tabs and windows so that malicious JavaScript cannot snoop on other pages and scripts via Spectre, which is what modern web browsers tend to do now. Again, the point of SplitSpectre is to demonstrate how Speculator can explore and potentially uncover future weaknesses in CPU microarchitectures.

The team's paper has an illustration of the SplitSpectre technique – pictured right – and explained the nitty-gritty: “A V1 gadget consists of a bounds check and two array accesses ... In order to mount a regular Spectre V1 attack, we would require a complete Spectre V1 gadget available in the JavaScript engine. The intuition behind SplitSpectre permits us to relax this requirement and only require the first half of a V1 gadget, i.e. the bounds check and the first array access.”

Mambretti stressed it's not a browser-reliant exploit, nor reliant on JavaScript. It pretty much affects code running concurrently on a shared interpreter. JavaScript was chosen because it can be embedded in malicious web pages or in emailed documents by miscreants attempting to pull private data out of the underlying environment. It's a relatively realistic attack scenario, in other words.

“We are only talking about SpiderMonkey and not browsers,” he said in an email. “SplitSpectre crosses the privilege boundary, between attacker-controlled JavaScript and the runtime environment, within the SpiderMonkey engine.”

The paper added: “The attack works ... we leak a string of ten characters with a success rate of over 80 per cent, and we leak the full string with a success rate of 10 per cent.”

Mambretti emphasized that a system fully patched against Spectre would be immune to SplitSpectre as it stands. The exploit is not tied to any particular CPU architecture, though the boffins tested their JavaScript on Intel Broadwell and Skylake CPUs, and AMD Ryzen chips. The research didn't specifically look at Arm-compatible components.

We pinged AMD and Intel for comment. AMD insisted its existing defense mechanisms block SplitSpectre. Intel declined to comment. We understand, though, Chipzilla's engineers are confident today's software mitigations defeat SplitSpectre.

Fuzzing the CPU's performance counter, for fun, and speculative execution

As Mambretti mentioned, the biggest road-bump spec-ex researchers face is that CPU vendors don't publish enough detail on their microarchitectures. The boffins decided they wanted a “tool whose purpose is to reverse-engineer the behaviour of different CPUs,” so they looked at the signals processors give the outside world that could identify two things: when spec-ex is happening, and, much more difficult, how to use that information to siphon data from memory holding sensitive information.

Speculator's architecture - click to embiggen

They drilled down on an interface CPU vendors provide to help optimise software: hardware performance counters.

The Speculator paper noted that these counters reveal “microarchitectural state changes such as cache accesses, retired instruction, and mispredicted branches,“ which can be used to "accurately measure microarchitectural state attributes associated to the speculative portion of the execution of user-supplied snippets of code.”

In other words, these counters keep track of how hard the CPU is working behind the scenes, and what exactly it may be up to, so as to maximize the rate of execution; this information can be used to pull off Spectre-based attacks. The kinds of thing Speculator observes in order to sniff out exploitable spec-ex weaknesses include:

Which code snippets are speculatively executed

What triggered spec-ex to start and stop

How specific instructions affect its behavior

Which security boundaries prevent spec-ex, for example the boundaries between kernel and user mode, and between a runtime engine and interpreted code

The consistency of CPU behavior within the same architecture or across different architectures.

Running Speculator showed Mambretti and his collaborators how to craft their new technique, SplitSpectre. They focused on instructions that are speculatively executed, but not retired, because those instructions provided insight into architectural side effects, side effects that formed a side-channel from which to lift bytes of private data. ®