Re: CVE-2016-2178: OpenSSL DSA follows a non-constant time codepath for certain operations

[Roman Drahtmueller <draht () schaltsekun de>]

> > The same principles apply when the computational burden is reversed for client auth, aren't they?
>
> Are you talking about the SSH target?
>
> If so, the realistic scenario is a user with legitimate credentials
> logging into a server to steal the DSA host key locally with cache
> timings.
>
> I don't think client-side enters into the equation for this vuln. You
> need an active attacker initiating handshakes. That's my 2c -- we
> didn't consider client-side victim much in this work.

The paper very resourceful, and thank you for sharing your thoughts 
even beyond it!

> If it's the TLS target, you need local access or manage to co-locate
> in cloud scenarios. Not as realistic as the SSH case IMO.


Control over CPU utilization (and thereby cache eviction) can be achieved 
by a remote attacker: Web applications are influenced remotely by 
definition, and they are far from slim or localized these days. 
Keepalives allow to keep the system in a sling with predictable resource 
utilization including cache fills, as there is not only just data stuffed 
through some buffers.

The question remains if the deterioration of the SNR (*) leaves enough 
resolution to be useful. This would no longer constitute a cache-based 
attack with the terrifyingly clear signal, but the sharp edges in the 
latency that you have demonstrated may contribute to filtering the effect 
from the noise. 
While the cause - non-constant-time implementation - remains.

Are the orders of magnitude in range?

R.

> BBB

(*):
-: network jitter, uncontrolled task concurrency
+: NIC offloading functions, cache coherency artefacts with multi 
threaded apps, carefully chosen timing between cache eviction activity 
and latency measurement of responses.