Danger of cache timing attacks
# Lars Hansen (9 years ago)
For the purposes of the proposed shared memory feature, this issue is tracked on that proposal's issue tracker: lars-t-hansen/ecmascript_sharedmem#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?)
# JF Bastien (9 years ago)
(Presumably PNaCl exposes the same problem?)
Yes.
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).
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.
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