Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel CPUs Vulnerable To New 'BranchScope' Attack (securityweek.com)

Posted by msmash on from the aftermath dept.

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).

59 of 102 comments (clear)

  1. Hype! Hype! Hype! by Anonymous Coward · · 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.

    1. Re:Hype! Hype! Hype! by Tablizer · · 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.

      --
      Table-ized A.I.
    2. Re:Hype! Hype! Hype! by Marxist+Hacker+42 · · 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.

      --
      SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
  2. Great by Anonymous Coward · · Score: 1

    I'll pencil this one in as "yet another Intel patch I won't be applying in 2018"

    1. Re:Great by greenwow · · 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

      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.

    2. Re:Great by AmiMoJo · · Score: 1

      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 Patch Tuesday and definitely better than them delaying or ignoring updates forever.

      The number of us power users who want to control the updates ourselves is fairly small, but it is immensely frustrating for us. And even for normal users, the updates should not interrupt normal use of their computer in any way.

      There doesn't seem to be a good solution. There are too many configurations out there to be sure a fix won't brick someone, and most users are not tech savvy enough to make good decisions about when to patch, and not getting timely patches is even worse.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    3. Re:Great by drinkypoo · · Score: 1

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    4. Re:Great by AmiMoJo · · Score: 1

      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 bricks, so you have no choice but to patch or face inevitable downtime...

      It really is an impossible situation.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    5. Re:Great by drinkypoo · · Score: 1

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:Great by AmiMoJo · · Score: 1

      Okay, so it's just about the timing. Small risk of bricking, but on the user's schedule.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    7. Re:Great by drinkypoo · · Score: 1

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  3. Media Bias is finally slowing down by naubrey · · Score: 2

    When the poo hit the AMD fan a few weeks ago it was front page news everywhere, but now that it has been slung back at Intel, it's good to see Ars is not making this article front and center, but rather downplaying it a bit. I actually had to search the front page to find it.

    1. Re:Media Bias is finally slowing down by HiThere · · Score: 3, 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.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  4. Re:God Damnit Intel by viperidaenz · · Score: 1

    Only if it's the low power, low performance versions with no out of order execution.
    You could also go with Intel Atom

  5. The cloud is safe they said by Anonymous Coward · · Score: 1, Funny

    VMs are safe they said
    You can't break out of your sandbox they said

  6. TL;DR by Anonymous Coward · · 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.

    1. Re:TL;DR by Anonymous Coward · · 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.

    2. Re:TL;DR by Bert64 · · Score: 1

      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.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    3. Re:TL;DR by Megol · · Score: 2

      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.

    4. Re:TL;DR by HiThere · · Score: 1

      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.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    5. Re:TL;DR by Anonymous Coward · · 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.

    6. Re:TL;DR by Anonymous Coward · · 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 make people reconsider shared VM hosting. You'll have people going back to dedicated server hosting, or maybe setting up their own non-shared VM environment in a dedicated server hosting environment.

      Yeah Joe Blow running his hobby blog on an EC2 instance really won't be able to afford to go the dedicated route, but I would say at this point any enterprise that has their stuff hosted in the cloud and isn't considering dedicated hosts is quite the fool.

    7. Re:TL;DR by sjames · · Score: 1

      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.

  7. [Corrections] Re:Hype! Hype! Hype! by Tablizer · · 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.)

    --
    Table-ized A.I.
  8. Re:Yawn by Megol · · Score: 1

    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!

  9. Nothing about AMD by Mister+Liberty · · Score: 2

    Although I expect Intel to correct that.

  10. Re:Yawn by HiThere · · Score: 1

    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.

    --

    I think we've pushed this "anyone can grow up to be president" thing too far.
  11. Re:God Damnit Intel by HiThere · · Score: 1

    IIUC, it's only the older models of the Atom that are safe. The more recent models have the same flaw.

    --

    I think we've pushed this "anyone can grow up to be president" thing too far.
  12. Re:Yawn by Mal-2 · · Score: 3, 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.

    --
    How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
  13. Yawn by Anonymous Coward · · 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.

  14. Accordingly... by beheaderaswp · · Score: 1

    There is no justice ... ... death is the only answer

    --
    Another consultant who stuck it out.

    "We are the Priests, of the Temples of Syrinx..."
  15. AMD needs to have ryzen pro with ipmi and ThreadRi by Joe_Dragon · · Score: 1

    AMD needs to have ryzen pro with ipmi (like Intel xeon-e3) and ThreadRipper boards (Xeon W).

  16. Great by nehumanuscrede · · Score: 2

    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 :|

  17. What? Yet *another* flaw in CPUs? by DontBeAMoran · · Score: 1

    SERENITY NOW!

    --
    #DeleteFacebook
  18. Re:God Damnit Intel by DontBeAMoran · · Score: 2

    Yeah after all those security problems, I'm almost expecting Apple to launch a new A10-powered laptop real soon now (TM).

    --
    #DeleteFacebook
  19. Responsible disclosure? by ElizabethGreene · · Score: 2

    It would be nice if they had worked with vendors to disclose this before publishing it. ... or did I miss that?

    1. Re:Responsible disclosure? by iggymanz · · Score: 1

      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.

  20. Re:Yawn by Anonymous Coward · · 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.

  21. Re:Yawn by Anonymous Coward · · Score: 1

    Citation please. TFA doesn't even clarify what "access" means in this case.

  22. Re: Yawn by Type44Q · · Score: 1

    First create a CPU core with a low level core for the base OS

    Kind of like Intel management engine running Minix...

  23. Re:Yawn by xxxLCxxx · · Score: 1

    Amen.

  24. Re:God Damnit Intel by HiThere · · Score: 1

    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.

    --

    I think we've pushed this "anyone can grow up to be president" thing too far.
  25. Re:Oh, snap! by Anonymous Coward · · Score: 1

    Now you know why INTeL was always faster than AMD... they cut corners where they shouldn't have.

  26. Eventually, yes by DrYak · · Score: 1

    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 to squeeze more performance
    - emulator getting more efficient at simulating the CPU.

    Worse part ?
    On intel architecture, that's already the case sometimes : Google's project zero managed to exactly pull this situation off, by running eBPF bytecodes (bytecode used by the programmable packet filtering virtual machine) on a few select Intel hardware.
    (On AMD, the same only work when JITing is activated, otherwise the speculative execution doesn't reach far enough).

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  27. Re:Isn't there access to the very core? by xxxLCxxx · · Score: 2

    Nope, there's not.
    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)...

  28. Re: Yawn by Killall+-9+Bash · · Score: 1

    It wouldn't be a terrible idea if it was open, and user(admin) accessible/configurable.

    --
    "Prediction: within 10 years, Windows will be a Linux distribution." Me, 7-6-2016
  29. Re:Yawn by Megol · · Score: 2

    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 fusion? Used on RISC. Instruction splitting? Used on RISC. Detection of special cases? Used on RISC (e.g. r0 or r31 defined as zero). Those are all optimization tricks.

  30. Re: Yawn by Marxist+Hacker+42 · · Score: 1

    Another reason to not use VMs or cloud technologies on machines you do not directly control.

    --
    SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
  31. Cloud Safety [Re:Hype! Hype! Hype!] by Tablizer · · Score: 1

    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 time the total deaths far exceeds deaths related to nuclear power plant accidents.)

    Therefore, the cloud has a PR problem, not so much a technical problem when it comes to security. It's not perfect by any stretch, but will probably be statistically better than the alternatives. But being statistically better may not be enough.

    --
    Table-ized A.I.
    1. Re:Cloud Safety [Re:Hype! Hype! Hype!] by scdeimos · · Score: 1

      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 feret out secret data from other instances on the physical machine.

    2. Re:Cloud Safety [Re:Hype! Hype! Hype!] by Marxist+Hacker+42 · · 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.

      --
      SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
    3. Re:Cloud Safety [Re:Hype! Hype! Hype!] by Tablizer · · 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.

      --
      Table-ized A.I.
    4. Re:Cloud Safety [Re:Hype! Hype! Hype!] by sjames · · Score: 1

      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.

  32. Re:Yawn by sheph · · Score: 1

    -1 = no sense of humor.

    --
    I don't believe in karma, I just call it like I see it.
  33. Re: AMD needs to have ryzen pro with ipmi and Thre by Brockmire · · Score: 1

    No one agreed with you the first 100 times you've said this. Give it a rest.

  34. uhhh... by SuperDre · · Score: 1

    If i have access and can run arbitrary code then I can do whatever on that computer.......... so this isn't really a vulnerability..

  35. Re:Yawn by Megol · · Score: 1

    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 had more incompatible extensions (reusing the same instruction encoding) and even a very incompatible change to extend the address space.

    I don't claim it's a beautiful design or that there aren't better ones just that it isn't too bad.

    --

    The main problem with x86 isn't decoding but finding the start/end of internal fields.

    [0-x prefixes] [op] [R/M] [SIB] [disp] [imm]

    ([op] can also be a [0xf] [op] in processors after the 8086/8088 for extended instructions)

    [0-x prefixes] [REX prefix] [op] [R/M] [SIB] [disp] [imm]

    REX is a special prefix added with AMD64.

    [0-x prefixes] [VEX prefix] [2|3 extension field] [op] [R/M] [SIB] [disp] [imm]

    SIB field is available for certain R/M encodings, added with the 386.

    x+rest of the instruction 15 bytes (maximum instruction length)

  36. Re:Yawn by xxxLCxxx · · Score: 1

    You have to admit that the x86 32-bit processors where really only 16-bit processors by design. They were about ten years behind when they got 'elected' by IBM.
    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 lights. They looked at the MMU as if it were a zit they could simply ignore while shaving. Meltdown cuts down the performance significantly. More appears to be coming.
    I'm exited to find out how much will be revealed in the end. If it rains down badly, all those processors will only be usable in single-user systems. MS-DOS is calling... ;-)

  37. Re:Yawn by sjames · · Score: 1

    No, access to a neighboring VM is sufficient. You can get that fairly cheap in the cloud.