11 ms·

BranchScope: A New Side-Channel Attack on Directional Branch Predictor

197 points by ianopolous 9y ago

JoachimSchipper 9y ago
This attack, "BranchScope", seems largely unrelated to Spectre - it's "just" another side-channel attack, allowing an attacker to learn which branches were taken by a victim process. BranchScope has a similar impact, and seems less convenient and slower, than pre-existing attacks that poke at the CPU cache. (Spectre 2 is scarier, because it allows the attacker to learn more-or-less anything accessible to the victim process.) Which isn't to say that this is bad work, nor even that the authors are over-hyping it (in fact, the paper mentions Spectre... very early in the introduction only.) But this article makes it easy to over-estimate the impact. As always, crypto code (in particular) must be constant-time (constant-everything) to avoid key recovery via such attacks. But again, that isn't new - cache-based attacks have broken lots of non-constant-time crypto code.
- mannykannot 9y ago
  The issue goes beyond the limited threat of any particular vulnerability. The larger issue is that we were blindsided by a category of systemic vulnerabilities that upend prior assumptions about the security of core principles of modern processor and operating system design, which raises doubt about our collective ability to identify and avoid risks in the design phase of computer and communications systems. Even if every individual aspect of these vulnerabilities had been recognized before, it is undeniable that the risks of their synergistic (from the point of view of an attacker) combination had not been properly appreciated prior to deployment of the affected technology, and for some time after.
  - akavel 9y ago
    Interestingly, there are people for whom this is of 0 surprise, and who built systems avoiding issues like this decades ago. See e.g. many comments by user https://news.ycombinator.com/threads?id=nickpsecurity https://news.ycombinator.com/threads?id=nickpsecurity, who tries to pursue a bona fide mission to educate. The main problem was of cost, and current "modern" processors are generally an example of the how the "it's cheaper to fail and then apologise" approach wins economically for consumer software.
    - TeMPOraL 9y ago
      > The main problem was of cost, and current "modern" processors are generally an example of the how the "it's cheaper to fail and then apologise" approach wins economically for consumer software. This happens everywhere; hell, that's how we ended up with Unix. "Worse is better".
  - lholden 9y ago
    Attacks against a host system of a virtual machine or of a shared system have been speculated about for quite a long time. I really do not think it should be a surprise to anyone that these vulnerabilities are being announced. Yeah, it certainly stands up shake up our industry... but I am not sure we were blindsided by it. Using shard or managed hardware has always been a compromise between the increased risk against the convenience. Nobody wants to build a data center out of their office anymore. Some of this risk can be mitigated by using managed but dedicated hardware. More expensive, but the option exists just about everywhere.
    - mannykannot 9y ago
      Based on the facts of how this problem has played out, I think it is an empirical fact that the major processor and operating system producers were blindsided by this issue, even though there were some people, such as Philip Guenther from OpenBSD, saying there is probably an exploit here. There seems to be a certain amount of after-the-fact analysis to the claim that no-one should have been surprised by this, and even that was, in fact, the case, the broader concern simply becomes one of why the situation was allowed to develop. In retrospect, we can say that people were making decisions that favored convenience over security, but were they aware at the time what specific compromises they were making? Either way, there is an important issue here that does not go away by saying they should or could have known.
userbinator 9y ago
It's been said multiple times and often dismissed, but it's becoming more evident that sharing the same hardware with untrusted code is not a good idea at all. Once again the biggest effect is on shared hosting/cloud services, while users of single-user personal computers and self-hosted services are quite immune by default... IMHO giving people more reasons not to run their code on and trust some server located remotely is a good thing. The researchers looked only at Intel processors, using the attacks to leak information protected using Intel's SGX (Software Guard Extensions), a feature found on certain chips to carve out small sections of encrypted code and data such that even the operating system (or virtualization software) cannot access it. Perhaps the other good thing to come of this. Fuck that DRM shit.
- giancarlostoro 9y ago
  > IMHO giving people more reasons not to run their code on and trust some server located remotely is a good thing. Or consider a colocation friendly host / dedicated hosting only. Of course this doesn't mean you have any guarantees there wont be any bad state actors on the premise at any moment (if this is a concern), but it beats sharing a machine with some skiddies.
  - sametmax 9y ago
    IMO any actor capable of leveraging successfully a branch prediction bug should not labeled a script kid anymore.
    - dasil003 9y ago
      ...right now.
      - sametmax 9y ago
        It should take a few years before you get a combination of attacks that are easy enough for a PHP cracker wanabee to pull out successfully and usefully. I hope most problems will be solved till then. But I get your point.
Arnt 9y ago
What I don't understand is: Why is this close coexistence with a untrusted code necessary or even beneficial? People run code from different security domains on the same L1/L2 cache. Why is that beneficial? Compared to, say, having the kernel flush the cache entirely whenever a context switch goes from one (uid/chroot/...) tuple to another, and only running processes/threads with the same tuple on the same cache at the same time?
- Someone1234 9y ago
  Performance. Usermode processes call privileged processes often (kernel APIs for example), if you flush the cache every time a context switch occurs, processing is now orders of magnitude slower. You can absolutely can do this today. It is just slow as heck.
  - coldtea 9y ago
    >Usermode processes call privileged processes often (kernel APIs for example), if you flush the cache every time a context switch occurs, processing is now orders of magnitude slower. Could there be a separate OS cache and a regular user code cache? Would it also speed up things (if cheap enough)?
    - Someone1234 9y ago
      Sure, but you'd require additional hardware and there's the backwards compatibility question (i.e. it has to work on both the traditional shared cache model AND the new split cache model, or you'd wind up with two versions of x86-64 that were incompatible).
      - zaarn 9y ago
        It could work in a backwards compatible manner like a lot of things. That could technically even be handled transparently by hardwiring caches for usage in Ring 3 or Ring 0 and then introducing additional opcode for explicitly allowing certain addresses to be put into Ring 3 cache when it goes into Ring 0 cache. PCID already does per-process caching, somewhat, though it's a bit neutered atm. The good thing is that it only needs to be backwards compatible in the sense that an OS that has no idea about this should at worst have a performance penalty. The hard point will be the additional hardware. L2 cache is expensive, L1 even moreso.
jballanc 9y ago
Question: would more widespread use of Unikernels (as opposed to virtualization and/or containers) mitigate the attack surface for this class of attacks?
- regularfry 9y ago
  Unikernels use virtualisation, so not really.
gargravarr 9y ago
I have just helped the Ubuntu developers diagnose a Spectre-induced bug in the kernel that caused several machines in our office to freeze with no messages on updating to new microcode. As a sysadmin, I am NOT looking forward to the next few months...
Mister_Snuggles 9y ago
I can only assume that code compiled with the M/o/Vfuscator[0] is immune to this as it does not use branch instructions. [0] https://github.com/xoreaxeaxeax/movfuscator https://github.com/xoreaxeaxeax/movfuscator

197 points by ianopolous 9y ago

This attack, "BranchScope", seems largely unrelated to Spectre - it's "just" another side-channel attack, allowing an attacker to learn which branches were taken by a victim process. BranchScope has a similar impact, and seems less convenient and slower, than pre-existing attacks that poke at the CPU cache. (Spectre 2 is scarier, because it allows the attacker to learn more-or-less anything accessible to the victim process.) Which isn't to say that this is bad work, nor even that the authors are over-hyping it (in fact, the paper mentions Spectre... very early in the introduction only.) But this article makes it easy to over-estimate the impact. As always, crypto code (in particular) must be constant-time (constant-everything) to avoid key recovery via such attacks. But again, that isn't new - cache-based attacks have broken lots of non-constant-time crypto code.

mannykannot 9y ago
The issue goes beyond the limited threat of any particular vulnerability. The larger issue is that we were blindsided by a category of systemic vulnerabilities that upend prior assumptions about the security of core principles of modern processor and operating system design, which raises doubt about our collective ability to identify and avoid risks in the design phase of computer and communications systems. Even if every individual aspect of these vulnerabilities had been recognized before, it is undeniable that the risks of their synergistic (from the point of view of an attacker) combination had not been properly appreciated prior to deployment of the affected technology, and for some time after.
- akavel 9y ago
  Interestingly, there are people for whom this is of 0 surprise, and who built systems avoiding issues like this decades ago. See e.g. many comments by user https://news.ycombinator.com/threads?id=nickpsecurity https://news.ycombinator.com/threads?id=nickpsecurity, who tries to pursue a bona fide mission to educate. The main problem was of cost, and current "modern" processors are generally an example of the how the "it's cheaper to fail and then apologise" approach wins economically for consumer software.
  - TeMPOraL 9y ago
    > The main problem was of cost, and current "modern" processors are generally an example of the how the "it's cheaper to fail and then apologise" approach wins economically for consumer software. This happens everywhere; hell, that's how we ended up with Unix. "Worse is better".
- lholden 9y ago
  Attacks against a host system of a virtual machine or of a shared system have been speculated about for quite a long time. I really do not think it should be a surprise to anyone that these vulnerabilities are being announced. Yeah, it certainly stands up shake up our industry... but I am not sure we were blindsided by it. Using shard or managed hardware has always been a compromise between the increased risk against the convenience. Nobody wants to build a data center out of their office anymore. Some of this risk can be mitigated by using managed but dedicated hardware. More expensive, but the option exists just about everywhere.
  - mannykannot 9y ago
    Based on the facts of how this problem has played out, I think it is an empirical fact that the major processor and operating system producers were blindsided by this issue, even though there were some people, such as Philip Guenther from OpenBSD, saying there is probably an exploit here. There seems to be a certain amount of after-the-fact analysis to the claim that no-one should have been surprised by this, and even that was, in fact, the case, the broader concern simply becomes one of why the situation was allowed to develop. In retrospect, we can say that people were making decisions that favored convenience over security, but were they aware at the time what specific compromises they were making? Either way, there is an important issue here that does not go away by saying they should or could have known.

userbinator 9y ago

It's been said multiple times and often dismissed, but it's becoming more evident that sharing the same hardware with untrusted code is not a good idea at all. Once again the biggest effect is on shared hosting/cloud services, while users of single-user personal computers and self-hosted services are quite immune by default... IMHO giving people more reasons not to run their code on and trust some server located remotely is a good thing. The researchers looked only at Intel processors, using the attacks to leak information protected using Intel's SGX (Software Guard Extensions), a feature found on certain chips to carve out small sections of encrypted code and data such that even the operating system (or virtualization software) cannot access it. Perhaps the other good thing to come of this. Fuck that DRM shit.

giancarlostoro 9y ago
> IMHO giving people more reasons not to run their code on and trust some server located remotely is a good thing. Or consider a colocation friendly host / dedicated hosting only. Of course this doesn't mean you have any guarantees there wont be any bad state actors on the premise at any moment (if this is a concern), but it beats sharing a machine with some skiddies.
- sametmax 9y ago
  IMO any actor capable of leveraging successfully a branch prediction bug should not labeled a script kid anymore.
  - dasil003 9y ago
    ...right now.
    - sametmax 9y ago
      It should take a few years before you get a combination of attacks that are easy enough for a PHP cracker wanabee to pull out successfully and usefully. I hope most problems will be solved till then. But I get your point.

Arnt 9y ago

What I don't understand is: Why is this close coexistence with a untrusted code necessary or even beneficial? People run code from different security domains on the same L1/L2 cache. Why is that beneficial? Compared to, say, having the kernel flush the cache entirely whenever a context switch goes from one (uid/chroot/...) tuple to another, and only running processes/threads with the same tuple on the same cache at the same time?

Someone1234 9y ago
Performance. Usermode processes call privileged processes often (kernel APIs for example), if you flush the cache every time a context switch occurs, processing is now orders of magnitude slower. You can absolutely can do this today. It is just slow as heck.
- coldtea 9y ago
  >Usermode processes call privileged processes often (kernel APIs for example), if you flush the cache every time a context switch occurs, processing is now orders of magnitude slower. Could there be a separate OS cache and a regular user code cache? Would it also speed up things (if cheap enough)?
  - Someone1234 9y ago
    Sure, but you'd require additional hardware and there's the backwards compatibility question (i.e. it has to work on both the traditional shared cache model AND the new split cache model, or you'd wind up with two versions of x86-64 that were incompatible).
    - zaarn 9y ago
      It could work in a backwards compatible manner like a lot of things. That could technically even be handled transparently by hardwiring caches for usage in Ring 3 or Ring 0 and then introducing additional opcode for explicitly allowing certain addresses to be put into Ring 3 cache when it goes into Ring 0 cache. PCID already does per-process caching, somewhat, though it's a bit neutered atm. The good thing is that it only needs to be backwards compatible in the sense that an OS that has no idea about this should at worst have a performance penalty. The hard point will be the additional hardware. L2 cache is expensive, L1 even moreso.

jballanc 9y ago

Question: would more widespread use of Unikernels (as opposed to virtualization and/or containers) mitigate the attack surface for this class of attacks?

regularfry 9y ago
Unikernels use virtualisation, so not really.

gargravarr 9y ago

I have just helped the Ubuntu developers diagnose a Spectre-induced bug in the kernel that caused several machines in our office to freeze with no messages on updating to new microcode. As a sysadmin, I am NOT looking forward to the next few months...

Mister_Snuggles 9y ago

I can only assume that code compiled with the M/o/Vfuscator[0] is immune to this as it does not use branch instructions. [0] https://github.com/xoreaxeaxeax/movfuscator https://github.com/xoreaxeaxeax/movfuscator