Intel CPUs Vulnerable To New 'BranchScope' Attack (securityweek.com) 102
wiredmikey writes: Researchers have discovered a new side-channel attack method dubbed "BranchScope" that can be launched against devices with Intel processors. The attack has been identified and demonstrated by a team of researchers, and similar to Meltdown and Spectre, can be exploited by an attacker to obtain potentially sensitive information they normally would not be able to access directly. The attacker needs to have access to the targeted system and they must be able to execute arbitrary code.
Researchers believe the requirements for such an attack are realistic, making it a serious threat to modern computers, "on par with other side-channel attacks." The BranchScope attack has been demonstrated on devices with three types of Intel i5 and i7 CPUs based on Skylake, Haswell and Sandy Bridge microarchitectures. Further reading: As predicted, more branch prediction processor attacks are discovered (ArsTechnica).
Researchers believe the requirements for such an attack are realistic, making it a serious threat to modern computers, "on par with other side-channel attacks." The BranchScope attack has been demonstrated on devices with three types of Intel i5 and i7 CPUs based on Skylake, Haswell and Sandy Bridge microarchitectures. Further reading: As predicted, more branch prediction processor attacks are discovered (ArsTechnica).
Hype! Hype! Hype! (Score:2, Insightful)
Every vulnerability needs a HYPED UP MARKETING NAME in the TECHSOCIAL INDUSTRY!!
EVERYTHING ABOUT TECH IS SOCIAL!!!!
Nerds who built all our technology, die in a fire. We the Social don't need nerds anymore.
Re:Hype! Hype! Hype! (Score:5, Insightful)
It's not hype in the sense that our IT stacks have so many layers, parts, and levels that it's nearly impossible to keep them all safe. Plus, co's rush products in order to stay ahead of competition at the expense of security.
Thus, they are indeed a steaming pile of leaks what should worry people. However, I will agree that focusing on specific problems may be a form of hype because for every 1 you hear about, there's probably dozens (already publicized) that you don't.
If people keep finding enough of these vulnerabilities, the patches will make the CPU run as slow as a Commodore 64. Maybe we should go back to '64s, eh? I got used to ASCII pr0n anyhow; I have a thing asterisks.
[Corrections] Re:Hype! Hype! Hype! (Score:1)
Correction #1: "...pile of leaks that should worry people."
#2: "I have a thing for asterisks."
Friggen Mondays. (I was off yesterday, so it's a mental monday.)
Re: (Score:1)
The people who should be worried, are those who store their data on cloud servers.
The average user storing stuff behind a firewall in his house or business, has no need to fear these attack vectors.
Cloud Safety [Re:Hype! Hype! Hype!] (Score:2)
I disagree the cloud is inherently less secure than the traditional approach. If one gives their "local" equipment and setups decent tender-loving-care, yes it's more secure than the cloud, but the average user won't bother, including many businesses.
The "problem" with the cloud is similar to nuclear power generation. Technically its record is safer than the alternatives. However, its failures make big news, which skews perceptions and fears. (Gas and coal kill through cancer and other ailments, and over ti
Re: (Score:2)
If cloud isn't inherently less secure than the traditional approach then why do Goog-azon-zure run separate GovClouds for government and military customers?
Ignoring network considerations the main reason cloud is less secure than local servers is because of shared infrastructure. Unless you're paying Goog-azon-zure top dollar for dedicated servers your instance is going to be sharing physical hardware with other customers. Side-channel attacks like this allow Nefarious Scumbag A to get one instance and fere
Re: (Score:1)
If you can break the VM barrier to read arbitrary memory anywhere on the iron, then yes, the security of the cloud is broken. If you don't have a dedicated server, you don't know who you are sharing with.
Re: (Score:1)
There's a lot of ways to breach dedicated servers also. Focusing on just Intel's cross-process goofs is too narrow a perspective.
Re: (Score:2)
The cloud can never be as safe as your own machines. When you set up a VM in the cloud, you're still running it. It's still you making it safe or not. If you can;t secure your own machine in your home or in a colo, you won't do any better running a VM in the cloud.
The difference is, in the cloud you don't know who else is running a VM on the same host. That opens up an attack surface that doesn't exist when you own your own.
Re: (Score:1)
Another reason to not use VMs or cloud technologies on machines you do not directly control.
Re: (Score:2)
can be exploited by an attacker to obtain potentially sensitive information
In other words, there is a one in a billion chance that an attacker would obtain something of importance.
Not in the given citation. Potentially means potentially, nothing more, nothing less.
The attacker needs to have access to the targeted system and they must be able to execute arbitrary code
In other words, a completely worthless exploit.
Getting arbitrary user code running is relatively easy and any exploit that can bypass any kind of protection from a user mode program is a real problem.
So two out of two wrong. Better luck next time!
Re: (Score:2)
This all depends on what "access" means. If it means browser drive-by, then it's quite dangerous. If it means physical access, then it's trivial.
Re:Yawn (Score:4, Insightful)
It's not trivial if it spans VMs, and one client of a hosting service can eavesdrop on another via this side channel. That has been the fear with Spectre and Meltdown, and it is most likely the fear here as well.
Re: (Score:1)
Re: (Score:2)
No, access to a neighboring VM is sufficient. You can get that fairly cheap in the cloud.
Re: Yawn (Score:2)
First create a CPU core with a low level core for the base OS
Kind of like Intel management engine running Minix...
Re: (Score:2)
Re: (Score:1)
Re: (Score:2, Insightful)
can be exploited by an attacker to obtain potentially sensitive information
In other words, there is a one in a billion chance that an attacker would obtain something of importance.
Yes, and when you have the computing power at your disposal to make billions of attempts per second it doesn't really take long at all.
Great (Score:1)
I'll pencil this one in as "yet another Intel patch I won't be applying in 2018"
Re: (Score:3, Informative)
Same here. We had several Dell Precision 5520 laptops bricked after installing:
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=NFKYX [dell.com]
We have several locations, and unfortunately our IT department didn't communicate that the update did that before I think five were bricked. We paid a lot extra for Dell's ProSupport Plus, but they have no solution yet and won't offer replacements.
Re: (Score:2)
Only if it's the low power, low performance versions with no out of order execution.
You could also go with Intel Atom
Re: (Score:2)
IIUC, it's only the older models of the Atom that are safe. The more recent models have the same flaw.
Re: (Score:2)
You've got me. It's an interesting question. OTOH, there are supposedly a lot of known ways of accessing the host computer from the VM, and perhaps those don't require out-of-order execution to implement.
Eventually, yes (Score:2)
can the code running on that emulated cpu achieve any of these out-of-order execution exploits against the host cpu running the emulator software?
It depends on the depth of the pipeline of the CPU.
If it long enough, the physical CPU might speculatively execute past the point where Qemu simulated the check in the emulated CPU, up to the point where Qemu simulate the payload that the attacker are wanting the emulated CPU to execute.
The thing is, for performance reason, if everybody switches to emulated CPUs (Java's / .NET's dreams), that's exactly the direction we will be heading onto :
- CPU getting longer pipeline (yet again, just like old P4) to try
AMD needs to have ryzen pro with ipmi and ThreadRi (Score:2)
AMD needs to have ryzen pro with ipmi (like Intel xeon-e3) and ThreadRipper boards (Xeon W).
Re: AMD needs to have ryzen pro with ipmi and Thre (Score:2)
Re: (Score:3)
Yeah after all those security problems, I'm almost expecting Apple to launch a new A10-powered laptop real soon now (TM).
Media Bias is finally slowing down (Score:2)
Re:Media Bias is finally slowing down (Score:4, Insightful)
Well, to be fair a lot of the hype about the AMD problem was because it was presented in a way that made it look as if Intel sponsored the release of information. I'm still not sure that isn't true.
The cloud is safe they said (Score:1, Funny)
VMs are safe they said
You can't break out of your sandbox they said
TL;DR (Score:1)
"The attacker needs to have access to the targeted system and they must be able to execute arbitrary code."
Non-news. Move along.
Re:TL;DR (Score:4, Insightful)
Non-news? Really? You can execute arbitrary code in virtual machines which could allow an attacker to access other running virtual machines or the host itself. This attack surface is absolutely HUGE! All an attacker has to due is get for example an Amazon Web Service instance and then be able to attack anything else running on that host. MASSIVE portions of the Internet run on services like AWS, VPS systems, etc.
Your browser can also present a target due to running Javascript or similar.
Re: (Score:2)
Commercial cloud providers *DO* have an open door policy, anyone could provision a virtual machine on a public cloud and use it to try and snoop on other customers running on the same physical host, although it may be difficult to target who you might be trying to snoop on.
Re: (Score:2, Informative)
You have no idea how these attacks work. You can execute arbitrary code on the physical machine. It may be inside a virtual machine but it's still executing on the physical hardware. That's the only requirement, executing arbitrary code on the CPU. You can do exactly that inside a VM and all the VM's are using the same CPU(s) therefore subject to attack.
You seem to mistakenly think that this requires physical access to the hardware or something.
Re: (Score:2)
The access doesn't have to be physical. All you need is the ability to run your own code. You can even get that for free with a trial account in many clouds.
Re: (Score:2)
You are making an assumption about what "access" means. It *might* mean physical access, but it could also include remote access. The summary, at least, wasn't clear about that.
Re: (Score:3)
Need to have access: Internet or any other network will do. No need for physical access.
Able to execute arbitrary code: many ways to do that.
Do you realize that Meltdown and the other Spectre exploits that made everyone rush to patch operating systems and user software require both access to a system and the ability to execute arbitrary code? In fact this looks like a variant of the Spectre family using another type of branch predictor manipulation.
Re: (Score:1)
The problem is VMs and cloud computing these days. Someone may not have physical ROOT access to your VM. but if they share a physical host with your VM and have full ROOT access on their VM, they can execute any arbitrary code they want inside their VM, potentially affecting your VM. All these exploits would pretty much be non-issues back in the old days of running a single OS per box on the bare metal. VMs make it a completely different story.
If these CPU exploits keep popping up, it is going to seriously
Nothing about AMD (Score:3)
Yawn (Score:1)
Another day, another Intel CPU vulnerability revealed. I'm beginning to wonder if we wouldn't all be better off using Motorola chips.
___
"Second place is first loser," whined the second loser, the third loser, the fourth loser... etc., mistakenly thinking they were being clever.
Re: (Score:1)
Re: (Score:2)
Technically the processors don't even belong to the customers. Intel still maintains full control over them, granting their buyers/users only very little of the same.
Unfortunately they also give full control over your management engine to others, if they want to. This machine (running MINIX on a power-efficient core) can then do - literally - anything behind your back, as you have no possibility to check what it is doing (which is exactly the way they want it to be)...
Re: (Score:3)
X86 isn't that bad. It's easier to decode than many other architectures, it's easier to make superscalar than many others, it support extensions of the instruction set. The last one is why we are still using x86.
X86 processors execute x86 instructions. They are x86 and only a subset of instructions aren't executed directly. There is no translation hardware unless you call the instruction decoding translation (technically correct) and then almost every processor made have/had translation hardware.
Instruction
Re: (Score:2)
Yes but the mess is due to its longevity! Remember we are talking about an architecture released in the 70's and now being 40 years old.
Core instructions aren't outdated with a few exceptions (when designing AMD64 some old instructions were removed and some reused), some instructions aren't used much anymore but are similar and execute in the same execution units as new extensions, some are just supported but not optimized for.
Compare with the original ARM instruction set which was released later but have h
Re: (Score:1)
With AMD64 the situation has improved. They look more like 32-bit processors nowadays.
About every year we had some extensions, which became obsolete a year-and-a-half later. The result of this policy is that most software doesn't make use of those 'nifty' extensions.
We are seeing now that Intel cheated. They did cut corners, and they did run red
Accordingly... (Score:2)
There is no justice ... ... death is the only answer
Great (Score:3)
Cue up another " hotfix " that will be deployed half a dozen times before it's ready to screw things up again. :|
My condolences in advance if you're running Windows 10 and the unstoppable update machine
Re: (Score:2)
Forced updates are a mixed blessing.
They generally roll them out slowly, so for example on Android app updates don't go to everyone on day one, they ramp up so that any issues can be detected before too many people are affected. Same with Windows 10.
On the one hand, this means that you might be unlucky and get bricked by a bad update and might be left vulnerable to zero day exploits for a week. On the other hand, for the vast majority of people it's both more reliable than everyone getting the update on Pat
Re: (Score:2)
They generally roll them out slowly, so for example on Android app updates don't go to everyone on day one, they ramp up so that any issues can be detected before too many people are affected. Same with Windows 10.
If just one user who wasn't ready to update has a broken update deployed to them that causes even the slightest problem with their computer, then too many users have been affected.
It's not acceptable for a vendor to push out packages when they want to, unless they warranty your system against failure due to bad patches. That kind of crap causes downtime.
Re: (Score:2)
Okay, but what is your solution?
Say you were an OS vendor with millions of users, all with different hardware and software configurations. You need to push out a critical security patch, but you obviously can't test with every single user's configuration. What do you do?
If any downtime at all is unacceptable, it seems like the only option is to leave everyone vulnerable. But then imagine it's a bug like the Apple calendar issues, where after a certain date important features stop working or the device even
Re: (Score:2)
Okay, but what is your solution?
Download the patches, and inform the user that they've been downloaded and ask them to install them on their schedule. But never, ever reboot the user's machine without their permission, or put it in a state which requires reboot.
Re: (Score:2)
Okay, so it's just about the timing. Small risk of bricking, but on the user's schedule.
Re: (Score:2)
Okay, so it's just about the timing. Small risk of bricking, but on the user's schedule.
No plan is perfect, and there is always a chance of failure. But it must happen on the user's schedule.
What? Yet *another* flaw in CPUs? (Score:2)
SERENITY NOW!
Re: (Score:1)
Now you know why INTeL was always faster than AMD... they cut corners where they shouldn't have.
Responsible disclosure? (Score:3)
It would be nice if they had worked with vendors to disclose this before publishing it. ... or did I miss that?
Re: (Score:2)
Your definition of "responsible" is rejected. No one has to abide by it. The flaws in Intel's tech has been known for a couple decades and they only move if their butt is metaphorically kicked, and even then they spend weeks just foundering rather than really fixing.
The major vendors are unworthy of such consideration. Assume the bad guys already know the exploit, that's the proper security mindset.
uhhh... (Score:2)