Slashdot Mirror
Researchers Detail New CPU Side-Channel Attack Named SpectreRSB (bleepingcomputer.com)
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.
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/...
What concerns me arent the attacks where the attackers binary is already running on my machine. What concerns me are the attacks that can be performed via "drive-by."
"His name was James Damore."
Glad I skipped this year. Wouldn't want to be anywhere NEAR Vegas.
ROWHAMMER are NOT new.. Intel should be on the hook for at _least_ the i7 and i9.
At some point Governments WILL have to start fining and banning these companies. What happens after that is likely going to be worse (architecture changes).
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.
"The attack works on Intel, AMD, and ARM processors, known to use RSB."
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
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."
all tech is garbage
Can you fuck off with the spam?? We get it, you're trying to get Slashdot to remove anon posting. On any other board even you would be downvoted.
Can't believe the first message in yet another thread is literally a fuckin copypasta bible of some rant.
Take your fuckin bots elswhere.
"The attack works on Intel, AMD, and ARM processors, known to use RSB."
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
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."
and , just to reiterate...
The attack works on Intel, AMD, and ARM processors, known to use RSB.
In related news, all Intel, ARM and AMD chips are affected by this and Meltdown if they are made by Intel.
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.
If you have systems in a consolidated server, at a cloud provider for example - then you should be concerned. A random attacker can rent a vm on the same hardware as yours then have all the needed time to attack your systems, eventually managing to extract your data. Once exploit code is out in the public, potentially anyone could do it with little effort.
Donâ(TM)t dismiss a security vulnerability, on the pretext that no valid use case comes to your mind at first thought. An attacker may happen to have better imagination than you have - especially if there is motivation to attack your systems.
Ever heard of virtualization and consolidation of systems on the same hardware? These days it is quite common for cloud service providers to stack multiple customers or the same hardware. Even you own the hardware, you may have systems of different security levels virtualized on the same hardware. An attacker that manages to compromise your perimeter web server can now attempt attacks against your internal systems, running on the same hypervisor.
Virtualization should never be used to replace physical security segmentation.
with a pop and a jump. Make life good again! Dump Trump is a shit hole country, like Iran! Put Trump in a red white and blue straight jacket and ship Trump off to Iran. Let them wacky Iranians deal with Trump. Two birds! One stone!
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.
I hope someone else gives a meaningful answer.
all tech is garbage
Can you fuck off with the spam?? We get it, you're trying to get Slashdot to remove anon posting.
Stating that "all tech is garbage" is not spam. It is a user stating an opinion, and it's an opinion that appears to be supported by TFA. What's wrong with that?
(Bonus question: Why should it matter whether the person stating an opinion is anonynous or not?)
The referenced article: Vulnerability of Speculative Processors to Cache Timing Side-Channel Mechanism
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.
Just rip this fucking unit out of the CPU and be done with it. Intel asshats.
Holy shit Cartman...do you ever shut up?
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..
Are you a fucking flat-earther? Fuck, you are dumb.