Danger of cache timing attacks

Lars Hansen 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?)

--lars

On Tue, Sep 29, 2015 at 1:20 AM, Waldemar Horwat <waldemar at google.com>
wrote:

> 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
> APIs).
>
> https://eprint.iacr.org/2015/898.pdf
>
> 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.
>
>     Waldemar
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150929/5e792801/attachment.html>


More information about the es-discuss mailing list