Danger of cache timing attacks
lhansen at mozilla.com
Tue Sep 29 09:29:03 UTC 2015
For the purposes of the proposed shared memory feature, this issue is
tracked on that proposal's issue tracker:
https://github.com/lars-t-hansen/ecmascript_sharedmem/issues/1. There's a
demonstration attached to that bug of a timer with about a 4ns resolution
on current hardware.
I don't mind discussing the matter on es-discuss but I hope nobody minds
that I copy salient information to the issue tracker.
(Presumably PNaCl exposes the same problem?)
On Tue, Sep 29, 2015 at 1:20 AM, Waldemar Horwat <waldemar at google.com>
> I was asked to share my concerns about how bad this can be. Here's a
> paper demonstrating how one AWS virtual machine has been able to
> practically break 2048-bit RSA by snooping into a different virtual machine
> using the same kind of shared cache timing attack. These were both running
> on unmodified public AWS, and much of the challenge was figuring out when
> the attacker was co-located with the victim since AWS runs a lot of other
> users' stuff. This attack would be far easier in shared-memory ECMAScript,
> where you have a much better idea of what else is running on the browser
> and the machine (at least in part because you can trigger it via other
> Chrome currently mitigates this by limiting the resolution of timers to
> 1µs. With any kind of shared memory multicore you can run busy-loops to
> increase the attack timing surface by 3½ orders of magnitude to about
> 0.3ns, making these attacks eminently practical.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss