Date: Thu, 9 Jun 2016 11:34:37 +0200 (CEST) From: Roman Drahtmueller <draht@...altsekun.de> To: oss-security@...ts.openwall.com, Billy Brumley <bbrumley@...il.com> Subject: Re: CVE-2016-2178: OpenSSL DSA follows a non-constant time codepath for certain operations > > > > 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.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ