add Spectre variant 2 mitigations

[Colin Watson]

On Tue, Feb 06, 2018 at 08:58:50PM +1030, David Newall wrote:
> On 06/02/18 19:52, Darren Tucker wrote:
> > On 6 February 2018 at 20:09, David Newall <openssh at davidnewall.com> wrote:
> > > Do we need to do anything?  It's not clear to me how SSH is vulnerable to
> > > Spectre -- that is, how SSH can be used to execute a Spectre attack?
> > I am more concerned with it being the target of a Spectre style
> > attack.  There's some long lived private data (host keys in the case
> > of sshd, session keys in the case of ssh and sshd and user keys in the
> > case of ssh-agent) and there's some scope to manipulate their
> > behaviour through external stimuli.
> 
> Indeed, but I'm not sure that SSH can be used in a Spectre attack; nor that
> using the mitigation strategies in SSH will do anything to prevent these
> keys from being stolen.  As I understand it, the likely way that SSH session
> keys will be stolen is by sending malicious JS to the browser.
> 
> I'm not saying that SSH needs no mitigation, I'm asking the question, "does
> it"?  Before we slow SSH down with the mitigation strategies, let's be sure
> there's a benefit to be gained.

Spectre variant 2 works by carefully flushing cached data and poisoning
the CPU's branch target buffer to convince it to speculatively execute
attacker-controlled code when it reaches indirect branches in the victim
code whose target address is loaded from memory, and then using side
channels to leak the result of that speculative execution in such a way
that it can be observed.  This means that if ssh/sshd/etc. contains any
such indirect branches (and virtually any non-trivial program does),
then any other process running on the same system can very likely suborn
it into leaking its secrets to the attacking process.

The point of the retpoline mitigations is to ensure that there are no
gadgets in the victim code for the attacker to get its claws into using
this technique.  So yes, in order to be effective here it would have to
be applied to OpenSSH, and based on my understanding of Spectre it seems
likely that doing so would be a useful mitigation, at least on
pre-Skylake Intel CPUs.

The practical bandwidth of these attacks as published so far is
relatively small (the Google Project Zero blog post about this [1] cited
1500 bytes/second for a particular variant of this), but the sort of
secrets that ssh/sshd/etc. has in memory are also pretty small, so it's
an obvious target.

JavaScript is a compelling vector for this kind of thing because it's a
way that untrusted code is commonly executed on people's computers, and
lots of people previously considered it to be safely enough sandboxed
(probably quite a few people still do), although its bandwidth is quite
a bit larger when using Meltdown.  However, it's certainly not the only
possibility.

There are other possible mitigations involving microcode updates and
kernel changes to make use of them, and if those are enabled then
retpoline isn't required.  However, my understanding is that on
pre-Skylake Intel CPUs those techniques are significantly slower than
retpoline.

Yes, this is all a nightmare.

-- 
Colin Watson                                       [cjwatson at debian.org]