Researchers Detail New CPU Side-Channel Attack Named SpectreRSB (bleepingcomputer.com) 39
An anonymous reader writes: "Scientists from the University of California, Riverside (UCR) have published details last week about a new Spectre-class attack that they call SpectreRSB," reports Bleeping Computer. "Just like all 'Spectre-class' attacks, SpectreRSB takes advantage of the process of speculative execution -- a feature found in all modern CPUs that has the role of improving performance by computing operations in advance and later discarding unneeded data. The difference from previous Spectre-like attacks is that SpectreRSB recovers data from the speculative execution process by attacking a different CPU component involved in this 'speculation' routine, namely the Return Stack Buffer (RSB)." In a research paper, academics say they've used SpectreRSB attacks to recover data belonging to other processes, and have even tricked the RSB into spilling SGX secrets. The attack works on Intel, AMD, and ARM processors, known to use RSB. The attack can also bypass all the mitigations put in place for the original Spectre/Meltdown flaws.
OpenBSD (Score:5, Interesting)
Because the RSB is shared among hardware threads that execute on the same virtual processor, this pollution enables inter-process, and even inter-VM, pollution of the RSB.
Well I guess there is a reason OpenBSD folks did this:
https://arstechnica.com/civis/... [arstechnica.com]
Re: (Score:2)
Because the RSB is shared among hardware threads that execute on the same virtual processor, this pollution enables inter-process, and even inter-VM, pollution of the RSB.
Well I guess there is a reason OpenBSD folks did this:
https://arstechnica.com/civis/... [arstechnica.com]
If it requires hyperthreading, how are ARM chips affected, and I assume in this case then only the Ryzen chips from AMD would be affected, since older AMD chips had no hyperthreading?
Re: (Score:2)
It doesn't. That's just one way of using it. All it requires is speculation regarding the return address. In this sense it's no different than previously discovered variants. The basic idea of all these attacks is that user space processes can get access to memory which would normally be protected.
Re: (Score:2)
It doesn't. That's just one way of using it. All it requires is speculation regarding the return address. In this sense it's no different than previously discovered variants. The basic idea of all these attacks is that user space processes can get access to memory which would normally be protected.
True, but depending on what mechanism they use to store information from the speculation they are sometimes bound by sharing the same cache or internal-cpu buffers.
doable from low privileged scripting languages? (Score:3)
Javascript and virtualisation as vectors (Score:5, Informative)
Javascript in browsers means EVERY workstation is running insecure remote code. Being this far from the hardware limits some attacks, but it basically gives the attackers all day, every day on every machine to work at it.
Cloud services (virtualisation) gives every attacker the opportunity to run their code on the same hardware as any number of potential victims. Again, they can attack all day, every day. They will win some, often enough to matter. It's like a giant bad guy lottery.
Re: (Score:1)
Javascript in browsers means EVERY workstation is running insecure remote code
Yes.... and can we all just take a moment and finally admit that running Javascript by default is a bad, bad, BAD idea?
That was always going to lead to a disaster.
What ARM processors are NOT susceptible to Spectre (Score:2)
What ARM processors are NOT susceptible to SpectreRSB? Some were said not to be susceptible to Meltdown and Spectre. For example, Eben Upton Explains Why Raspberry Pi Isn't Vulnerable To Spectre Or Meltdown [slashdot.org]
Quote: "The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort."
Please answer the question. (Score:2)
What ARM processors are NOT susceptible to Spectre (Score:3)
Quote: "The majority of Arm processors are not impacted by any variation of this side-channel speculation mechanism. A definitive list of the small subset of Arm-designed processors that are susceptible can be found below."
Question: What processors are NOT vulnerable? The article lists only the processors that ARE vulnerable.
"The attack works on Intel, AMD, and ARM ..." (Score:5, Informative)
Citation needed. I'll provide the one in the paper: "Although we did not demonstrate attacks on AMD and ARM processors, they also use RSBs to predict return addresses"
I'll also note that the only demonstrated working attack is against Intel SGX enclaves, something that is Intel specific. There are demonstrations that do not expose information within a process and between two co-operating processes however those are normally not a security problem.
No doubt some type of attack using the return address stack is possible on AMD, ARM, and other processors with branch prediction. However that isn't demonstrated and it isn't claimed in the linked paper.
Vulnerability description (Score:3, Informative)
Here's a summary of the vulnerability, for those of you who don't want to (or don't have the time to) read TFA.
Every modern CPU has a branch predictor to make it possible to speculatively execute instructions after a branch instruction (a jump to code at another memory location). However, branch predictors often don't perform particularly well for the return instructions that occur at the end of a function, since a single function might be called lots of times from various other functions. So to aid in speculatively executing instructions after a return instruction, any manufacturers have added a return stack buffer, or RSB for short, to their processors.
It works like this. When a call instruction is executed, the address of the next instruction is placed on the stack, to be later taken from the stack by the return instruction that makes execution return to that address. Wouldn't it be great if you could use this address instead of the branch predictor when speculatively executing a return instruction? Unfortunately, doing this would force you to exactly keep track of what the stack pointer is doing and speculatively load the memory page containing that part of the stack and then speculatively read the return address from it. This is a lot of work. But we want to get the result of all this work to the return instruction when it is speculatively executed, so fairly ahead of time, otherwise there'd be no point in trying to speculatively execute it as you might as well just end the pipeline at every return instruction and just normally execute it in that case. And this is where the RSB comes in. Most of the time the return address doesn't change, so when a call instruction is executed, the processor doesn't just push it on the stack, but also on a fairly small stack of return addresses within the CPU itself. This is the RSB. When the corresponding return instruction is speculatively executed, the CPU consults the RSB to determine the return address and continues speculatively executing instructions from there.
So how can this be exploited? Suppose you have a call instruction immediately followed by code that reads a value from memory you aren't supposed to be able to access and then uses that value to index into an array and read a value from that array. The call instruction itself jumps to code that changes the return address on the stack to the actual code to execute next and then returns. When this return instruction is speculatively executed, the RSB is consulted and the normally inaccessible value is speculatively read. Of course during normal execution that would trigger an access violation exception, but during speculative execution the read happens before any access checks have been completed. So this value can be speculatively used to index into the array and the next speculative read from the array will pull a page from the array into the CPU cache. However, as the pipeline advances and the return instruction starts to be committed, the CPU realises the value on the stack doesn't match the value in the RSB. The pipeline stalls and the return instruction jumps to the actual return address, where some code is located to probe the processor cache. Based on the timing, the aforementioned value located in supposedly inaccessible memory can be deduced, even though it was only speculatively read and never officially.
The article contains some more examples of inter-thread, inter-process, and inter-privilege-mode shenanigans, but this is the gist of it.
Looking for neighbors (Score:2)
I wonder if VPS providers will have to throttle VM creation because nefarious people spin up VMs looking for a particular neighboring host on the same physical server..