This article is more than 1 year old
Ready for another fright? Spectre flaws in today's computer chips can be exploited to hide, run stealthy malware
Honey, I've shrunk the spyware and concealed it with speculative execution
Spectre – the security vulnerabilities in modern CPUs' speculative execution engines that can be exploited to steal sensitive data – just won't quietly die in the IT world.
Its unwelcome persistence isn't merely a consequence of the long lead time required to implement mitigations in chip architecture; it's also sustained by its ability to inspire novel attack techniques.
The latest of these appeared in a paper presented at the Network and Distributed Systems Security (NDSS) Symposium 2019 in San Diego, California, on Monday.
Co-authored by three computer science boffins from the University of Colorado, Boulder in the US – Jack Wampler, Ian Martiny, and Eric Wustrow – the paper, "ExSpectre: Hiding Malware in Speculative Execution," describes a way to compile malicious code into a seemingly innocuous payload binary, so it can be executed through speculative execution without detection.
Speculative execution is a technique in modern processors that's used to improve performance, alongside out-of-order execution and branch prediction. CPUs will speculate about future instructions and execute them, keeping the results and saving time if they've guessed the program path correctly and discarding them if not.
But last year's Spectre flaws showed that sensitive transient data arising from these forward-looking calculations can be exfiltrated and abused. Now it turns out that this feature of chip architecture can be used to conceal malicious computation in the "speculative world."
Data-spewing Spectre chip flaws can't be killed by software alone, Google boffins concludeREAD MORE
The Boulder-based boffins have devised a way in which a payload program and a trigger program can interact to perform concealed calculations. The payload and trigger program would be installed through commonly used attack vectors (e.g. trojan code, a remote exploit, or phishing) and need to run on the same CPU. The trigger program can also take the form of special input to the payload or a resident application that interacts with the payload program.
"When a separate trigger program runs on the same machine, it mistrains the CPU’s branch predictor, causing the payload program to speculatively execute its malicious payload, which communicates speculative results back to the rest of the payload program to change its real-world behavior," the paper explains.
The result is stealth malware. It defies detection through current reverse engineering techniques because it executes in a transient environment not accessible to static or dynamic analysis used by most current security engines. Even if the trigger program is detected and removed the payload code will remain operating.
There are limits to this technique, however. Among other constraints, the malicious code can only consist of somewhere between one hundred and two hundred instructions. And the rate at which data can be obtained isn't particularly speedy: the researchers devised a speculative primitive that could decrypt 1KB of data and exfiltrate it at a rate of 5.38 Kbps, assuming 20 redundant iterations to ensure data correctness.
To accommodate these constraints and craft efficient malware, the boffins devised a custom emulator and 6-bit instruction set called SPASM (Speculative Assembly).
"Using SPASM, developers can write programs, assemble and encrypt them into a payload program," the paper explains. "When the associated trigger program runs, the payload will decrypt SPASM instructions in the speculative world, and execute them one at a time."
The Colorado compu-boffins come to the same conclusion as other security researchers who have explored Spectre-related issues: these flaws need to be addressed in silicon and microarchitecture patches.
"Until then, attackers may iterate and find new variants of ExSpectrelike malware," they say. "In the meantime, new detection techniques and software-level mitigations are desperately needed." ®