{"id":21334,"date":"2018-12-07T23:59:13","date_gmt":"2018-12-07T23:59:13","guid":{"rendered":"https:\/\/www.threatshub.org\/blog\/in-case-youre-not-already-sick-of-spectre-boffins-demo-speculator-tool-for-sniffing-out-data-leaking-cpu-holes\/"},"modified":"2018-12-07T23:59:13","modified_gmt":"2018-12-07T23:59:13","slug":"in-case-youre-not-already-sick-of-spectre-boffins-demo-speculator-tool-for-sniffing-out-data-leaking-cpu-holes","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/in-case-youre-not-already-sick-of-spectre-boffins-demo-speculator-tool-for-sniffing-out-data-leaking-cpu-holes\/","title":{"rendered":"In case you’re not already sick of Spectre… Boffins demo Speculator tool for sniffing out data-leaking CPU holes"},"content":{"rendered":"

Analysis<\/strong> 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.<\/p>\n

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<\/a> in an academic paper emitted earlier this week.<\/p>\n

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

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.<\/p>\n

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.<\/p>\n

Mambertti explained to The Register<\/em> Speculator came about from \u201cthe analysis of common elements of [speculative exexecution] attacks,” and should “help the analysis of new and old attacks.<\/p>\n

\u201cSplitSpectre 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.\u201d<\/p>\n

SplitSpectre: If you patched, relax<\/span><\/h3>\n

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

This particular variation was dubbed SplitSpectre, and it differs from previous exploits by \u201crequiring a smaller piece of vulnerable code available in the victim\u2019s attack surface.\u201d 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\"Flow<\/a><\/div>\n

The team’s paper has an illustration of the SplitSpectre technique \u2013 pictured right<\/em> \u2013 and explained the nitty-gritty: \u201cA 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.\u201d<\/p>\n

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.<\/p>\n

\u201cWe are only talking about SpiderMonkey and not browsers,\u201d he said in an email. \u201cSplitSpectre crosses the privilege boundary, between attacker-controlled JavaScript and the runtime environment, within the SpiderMonkey engine.\u201d<\/p>\n

The paper added: \u201cThe 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.\u201d<\/p>\n

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.<\/p>\n

We pinged AMD and Intel for comment. AMD insisted its existing defense mechanisms<\/a> block SplitSpectre. Intel declined to comment. We understand, though, Chipzilla’s engineers are confident today’s software mitigations defeat SplitSpectre.<\/p>\n

Fuzzing the CPU’s performance counter, for fun, and speculative execution<\/span><\/h3>\n

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 \u201ctool whose purpose is to reverse-engineer the behaviour of different CPUs,\u201d 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.<\/p>\n

\"Speculator<\/a><\/p>\n

Speculator’s architecture – click to embiggen<\/p>\n<\/div>\n

They drilled down on an interface CPU vendors provide to help optimise software: hardware performance counters.<\/p>\n

The Speculator paper noted that these counters reveal \u201cmicroarchitectural state changes such as cache accesses, retired instruction, and mispredicted branches,\u201c which can be used to “accurately measure microarchitectural state attributes associated to the speculative portion of the execution of user-supplied snippets of code.\u201d<\/p>\n

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:<\/p>\n