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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx] _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
