A ghost

Google security researchers have analyzed the impact of the data-leaking Spectre vulnerabilities afflicting today’s processor cores, and concluded software alone cannot prevent exploitation.

The Chocolate Factory brainiacs – Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer, Toon Verwaest – show that they can construct what’s dubbed a universal gadget to exploit the spectre gang of speculative-execution flaws present in various CPU families, allowing attacker-supplied code running in a thread to read all memory in the same address space.

This means, for example, a malicious webpage’s JavaScript code executing in a web browser thread can potentially snoop on another webpage’s JavaScript running in another thread, and steal secret data from that other page. There are already mitigations in place in browsers, such as Chrome’s Site Isolation that keeps webpages in separate processes, limiting what any malicious JavaScript can spy on. Firefox, Internet Explorer, and Edge, at least, block the use of JS object SharedArrayBuffer, which can be exploited to perform Spectre snooping.

However, the underlying threat is still there for any applications interpreting attacker-supplied code. Language-based defenses and similar safeguards within a process can’t stop Spectre; you have to go down to hardware-based separation using individual processes with their own individual virtual address spaces and hardware-enforced page tables.

Threat or hype?

Since there aren’t many other scenarios in which attacker-supplied code is interpreted in the same address space as other user-supplied code – web browsers spring to mind, chiefly – the Googlers’ research is largely academic, and not something to immediately panic over. However, if you’re developing software that interprets external code, this is something to be very much aware of.

“We now believe that speculative vulnerabilities on today’s hardware defeat all language-enforced confidentiality with no known comprehensive software mitigations, as we have discovered that untrusted code can construct a universal read gadget to read all memory in the same address space through side-channels,” the researchers say in a paper distributed through pre-print service ArXiv.

The paper is titled “Spectre is here to stay: An analysis of side-channels and speculative execution.”

Shortly after The Register first reported the Spectre and Meltdown bugs in January 2018, University of Michigan assistant professor of computer science Daniel Genkin, a co-author of the original Spectre research paper who was a postdoctoral student at the time, said as much: “We are currently not aware of effective countermeasures that will eliminate the root cause of Spectre, short of hardware redesign,” he told The Registerlast year.

Spectre, as its name suggests, involves the exploitation of speculative execution, a feature of modern processors that involves guessing the future path of a program and making anticipated calculations while the processor is busy with other tasks.

These calculations can be retained if the correct path was guessed, which saves time and hastens code execution. But as the Spectre flaws demonstrated, the ability to peer into the future can be abused.

There are several Spectre variants but the basic problem is that chip designers traded security for speed. “Our models, our mental models, are wrong; we have been trading security for performance and complexity all along and didn’t know it,” the researchers observe.

Variant 4, Speculative Aliasing Confusion, has no software solution that Google’s researchers could find. “Variant 4 defeats everything we could think of,” the researchers say.

Initially, software and hardware makers pushed fixes like microcode updates and techniques like Retpoline. Browser makers Google and Mozilla made timing data less accessible, to make speculative execution attacks more difficult.

But that appears to be futile. “We argue that mitigating timing channels by manipulating timers is impossible, nonsensical, and in any case ultimately self-defeating,” the researchers say.

Google’s boffins added defenses against Spectre into the V8 JavaScript virtual machine within the company’s Chrome browser and found the performance penalties frustrating because they slow things down without truly fixing the problem. “None of these mitigations provide comprehensive protection against Spectre, and so the mitigation space is a frustrating performance / protection trade-off,” they say.

That’s why Google shifted its browser security focus to the aforementioned site isolation. But help has to come from hardware, too, in the form of better process isolation.

Intel announced hardware fixes for some of the Spectre vulnerabilities in March 2018, but its claim that Spectre Variant 1 “will continue to be addressed via software mitigations” now looks rather dubious.

[“source=theregister”]