
BranchScope: A New Side-Channel Attack on Directional Branch Predictor - ianopolous
https://arstechnica.com/gadgets/2018/03/its-not-just-spectre-researchers-reveal-more-branch-prediction-attacks/
======
userbinator
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.

~~~
anon1385
>users of single-user personal computers and self-hosted services are quite
immune by default

Well, except for people using web browsers…

~~~
andy_ppp
Yes was going to say exactly this; how dangerous is Javascript, Image Decoding
and Web Assembly in this new world?

~~~
simias
Javascript and Web Assembly are only dangerous because of this insane policy
on the web that everything is whitelisted by default. Fortunately there are
extensions to change that behavior but most people won't bother with them,
leading web developers to assume that JS is enabled and the site breaking if
it's not.

In our rush to get rid of Flash on the web we turned the web into Flash. At
least it's an open standard now, I suppose.

Images and other codecs might also be an issue but it seems like a more
complicated attack vector and one that could be mitigated more effectively.

------
JoachimSchipper
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
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
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
> _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".

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

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

~~~
Arnt
I've heard that before, it doesn't seem quite credible once you factor out the
performance-critical code that tries to minimise context switches, and the API
usage that involves a LAN.

It seems to boil down to performance-critical untrusted code that performs
many kernel calls.

~~~
Someone1234
> I've heard that before, it doesn't seem quite credible

It doesn't seem credible that completely clearing cache and repopulating it
every time a privileged context switch occurs would cause performance
degradation?

> It seems to boil down to performance-critical untrusted code that performs
> many kernel calls.

You're conflating the current branch prediction hotfixes with what the person
above asked about which was completely clearing cache when the context is
switched into a privileged state. Those are two entirely different things.

The current hotfixes try to continue to utilize many performance benefits of
speculative execution, while patching out the side-channel attacks from branch
prediction. The person above was asking about a complete change in the
underlying model we use today, which would promote security at the cost of
performance.

~~~
Arnt
Would cause much performance degradation _where it matters most_.

I run some heavy jobs today. Many CPU seconds each. I don't see that those
have to suffer. They can stay married to a CPU core for seconds at a time,
uninterrupted, just like today. They perform few system calls, and the ones
they do perform never fail any in-kernel check.

The javascript that runs in the browser suffers, sure, but that javascript has
other reasons not to need several seconds of CPU.

BTW, that person was me, and you misunderstand the question. Not into a
privileged state. Out of. Such that an unprivileged/unstrusted process would
see cache contents produced by others.

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

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

~~~
regularfry
Unikernels use virtualisation, so not really.

