Spectre rises from the dead to bite Intel in the return stack buffer

Panic not: Invincible ghost in the machine dispelled by latest mitigations, we're told

spectre

Updated Spectre, a class of vulnerabilities in the speculative execution mechanism employed in modern processor chips, is living up to its name by proving to be unkillable.

Amid a series of mitigations proposed by Intel, Google and others, recent claims by Dartmouth computer scientists to have solved Spectre variant 1, and a proposed chip design fix called SafeSpec, new variants and sub-variants keep appearing.

The findings also revive doubts about whether current and past chip designs can ever be truly fixed.

Only two weeks ago, researchers Vladimir Kiriansky and Carl Waldspurger disclosed new data-stealing exploits, dubbed Spectre 1.1 and 1.2 [PDF].

Now there's another called SpectreRSB that exploits the return stack buffer (RSB), a system in modern CPUs used to help predict return addresses, instead of the branch predictor unit.

In a paper titled Spectre Returns! Speculation Attacks using the Return Stack Buffer, distributed through pre-print server ArXiv, boffins Esmaeil Mohammadian Koruyeh, Khaled Khasawneh, Chengyu Song, and Nael Abu-Ghazaleh detail a new class of Spectre attack that accomplished the same thing as Spectre variant 1 – allowing malicious software to steal passwords, keys, and other sensitive information, from memory it shouldn't be allowed to touch.

These researchers, incidentally, are among those who developed the SafeSpec mitigation.

The latest data-theft technique involves forcing the processor to misspeculate using the RSB. Using a call instruction on x86, SpectreRSB allows an attacker to push a value to the RSB so that the return address for the call instruction no longer matches the contents of the RSB.

The paper, dated July 20, outlines the steps involved in the SpectreRSB attack, which itself has six variants:

"(1) after a context switch to the attacker, s/he flushes shared address entries (for flush reload). The attacker also pollutes the RSB with the target address of a payload gadget in the victim’s address space; (2) the attacker yields the CPU to the victim; (3) The victim eventually executes a return, causing speculative execution at the address on the RSB that was injected by the attacker. Steps 4 and 5 switch back to the attacker to measure the leakage."

The paper also provides some sample code:

1. Function gadget()
2. {
3.   push %rbp
4.   mov %rsp, %rbp
5.   pop %rdi //remove frame/return address
6.   pop %rdi //from stack stopping at
7.   pop %rdi //next return address
8.   nop
9.   pop %rbp
10.  clflush (%rsp) //flush the return address
11.  cpuid
12.  retq //triggers speculative return to 17
13. } //committed return goes to 23
14. Function speculative(char *secret_ptr)
15. {
16.  gadget(); //modify the Software stack
17.  secret = *secret_ptr; //Speculative return here
18.  temp &= Array[secret * 256]; //Access Array
19. }
20. Function main()
21. {
22.  speculative(secret_address);
23.  for (i = 1 to 256) //Actual return to here
24.  {
25.   t1 = rdtscp();
26.   junk = Array[i * 256]; //check cache hit
27.   t2 = rdtscp();
28.  }
29. }

The researchers have tested SpectreRSB on Intel Haswell and Skylake processors and the SGX2 secure enclave in a Core i7 Skylake chip. They did not test AMD nor Arm cores but note that both chipmakers use RSBs and so they reported their findings to them just in case, as well as to Chipzilla.

The eggheads claimed "none of the known defenses including [Google's] Retpoline and Intel’s microcode patches stop all SpectreRSB attacks."

However, a spokesperson for Intel told us the Xeon maker believes mitigations already available to programmers really do thwart SpectreRSB side-channel shenanigans:

SpectreRSB is related to Branch Target Injection (CVE-2017-5715), and we expect that the exploits described in this paper are mitigated in the same manner. We have already published guidance for developers in the whitepaper, Speculative Execution Side Channel Mitigations. We are thankful for the ongoing work of the research community as we collectively work to help protect customers.

You can find Intel's mitigation white paper, here [PDF]. Spokespeople for AMD and Arm were not available for immediate comment.

ELF'n'safety

Last week, researchers at Dartmouth suggested a defense against Spectre variant one, to which Intel previously proposed adding the LFENCE instruction to code as a defense against speculative execution.

The Dartmouth solution involves using something called ELFbac policy techniques. In an email to The Register, Dartmouth PhD student Prashant Anantharaman explained that ELFbac lets programmers set policies for memory permissions. Effectively, a program's ELF executable tells the operating system how to ring-fence particular areas of memory to hopefully thwart Spectre side-channel attacks.

"The permissions set here for the page-tables are also respected by the speculative execution branches, and hence if the developer intends to protect certain secrets within the program, the attacker exploiting Spectre would still not be able to gain access to these secrets," he said. "These policies are defined at the ABI-level using the existing capabilities of the static linker and the build tool-chain."

Anantharaman said the technique, which is enforced through Linux kernel memory management mechanisms, can be generalized for use against a larger class of intra-process memory attacks.

Asked via email whether he's seen the Dartmouth research, Nael Abu-Ghazaleh, professor of computer science and engineering at UC Riverside and a coauthor of the SpectreRSB paper, told The Register that he had reviewed it briefly.

"From the information I can find it has a strong flavor of basically doing the KPTI solution but at the user level software (i.e., map regions of memory where the secrets are only when you need them)," he said. "This is likely to have a substantial performance overhead, especially if the secret data is accessed often. Moreover, the programmer has to be disciplined enough to isolate all the secret data."

Abu-Ghazaleh said there's value in software-based fixes, but it's not enough.

As computer science researcher Daniel Genkin told The Register in January, Abu-Ghazaleh believes that chip will have to be redesigned to eliminate speculative execution flaws.

"Although patching is important, we need to consider this class of vulnerability in the design of new processors to completely address the problem," he said. ®

Updated to add

AMD also says current side-channel mitigations kill SpectreRSB dead. A spokesperson told us:

AMD is aware of a new research paper on processor speculation and a proposed vulnerability in the return stack buffer. AMD believes its recommended Indirect Branch Prediction Barrier (IBPB) setting mitigates against the described vulnerability. As stated in this AMD Whitepaper, when IBPB is set in software for context switching, the processor enforces that older indirect branches cannot influence predictions of indirect branches in the future, we believe thereby effectively mitigating against the described vulnerability.

Meanwhile, a spokesperson for Arm said: "We are aware of this report and updated information is available on our security update page."

It is understood that while SpectreRSB is a true sub-variant of Spectre, it is mitigated by today's defense mechanisms in spite of the paper's conclusions, according to chip and software engineers. Not that any malware is exploiting these side-channels in real attacks right now anyway.




Biting the hand that feeds IT © 1998–2018