4 ms·
If Chrome is going to ship SharedArrayBuffer, then why will the resolution of performance.now() and other timer APIs continue to be neutered? I don't have any p
by Sephr 10y ago
If Chrome is going to ship SharedArrayBuffer, then why will the resolution of performance.now() and other timer APIs continue to be neutered? I don't have any preference one way or the other for implementing SharedArrayBuffer, but I am fully against neutering timers with jitter if a vendor does choose to implement SharedArrayBuffer. Random additional timer jitter becomes a false layer of security in this scenario, and https://bugs.chromium.org/p/chromium/issues/detail?id=506723 https://bugs.chromium.org/p/chromium/issues/detail?id=506723 should be reverted.
With SharedArrayBuffer you can easily implement extremely high resolution sub-nanosecond timers and open the door to new timing attacks. For example, here is a high resolution SharedArrayBuffer timer: https://codepen.io/yossioren/pen/LVBNMR https://codepen.io/yossioren/pen/LVBNMR
For more discussion regarding the security implications of this change, see https://github.com/tc39/ecmascript_sharedmem/issues/1 https://github.com/tc39/ecmascript_sharedmem/issues/1 . Some of the security problems may be mitigable with Intel CAT, although I am not aware of Chrome making use of that yet.
- skrebbel 10y agoIs there any layman's introduction to this subject? I can't comprehend how having an accurate timer lets me steal information from other processes.
- Sephr 10y agoThe papers "The Spy in the Sandbox -- Practical Cache Attacks in Javascript" at https://arxiv.org/pdf/1502.07373.pdf https://arxiv.org/pdf/1502.07373.pdf and "ASLR on the Line: Practical Cache Attacks on the MMU" at http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pdf http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pd... are good starting points, though they are not very accessible to a layman. There have even been timing attacks that let you recover AES keys from analyzing a device's power usage. In layman's terms: computers are extremely complicated beasts of coordinated timing of software and hardware, and timing data leaks many things about what a piece of software is doing. This is the reason that many modern encryption libraries pad operations as a defense against timing attacks.
- skrebbel 10y agoThanks. I had actually started reading The Spy in the Sandbox but it was too hardcore for me. So, how does this work? I set a timer, and then read the time a bit later, and somehow I recovered an AES key from a different process? I'm still missing a piece :-) Notably, how can timing data leak things? I mean, I can see how I can do 1. Start hi-res timer 2. Kick off something that involves out-of-sandbox data 3. Stop hi-res timer and do this often enough and with well-tuned input to read useful data out. Is that how it works? But how can I use this to read stuff in entirely different processes? Moreover, how can I do that in a targeted manner? Eg I suspect my target is using internet banking but I don't know which other programs are running, how many cores the machine has, etc etc etc.
- techdragon 10y agoTo be very simplistic, timing attacks are a bit like buffer overflows, if you do then just right you can use them to read information about other processes, such as processes you aren't meant to be able to see into. Where they are different is that timing attacks usually serve as information extraction tools, which attackers can choose to further leverage by basing subsequent attacks on the information they obtained, where as buffer overflow attacks can do pretty much anything up to and including rooting a box or breaking out of a hypervisor.
- Dylan16807 10y ago> Notably, how can timing data leak things? That part's simple. Naive crypto code will often vary in speed based on the data. A 0 bit in the key causes some behavior, a 1 bit causes some slightly different behavior, and suddenly if you can measure the length of each step you can recover the secrets. Getting the timing data is a little bit trickier from javascript, but it's also simple in concept. As sensitive code runs, it affects the CPU cache. Javascript can use memory locations that go in the same cache slots as sensitive code. This goes a few nanoseconds faster or slower based on what parts of the sensitive code have finished. Now you have timing data. If you don't know what else is running or if you're on the same core, you just have to try repeatedly.
- 10y ago
- DasIch 10y agoThe amount of time something takes is often related to the input. Measuring the time, gives you information on that input. For example measuring the time of a=b with constant b tells you roughly how large a[:n] such that a[:n] = b[:n].
- ballenf 10y agoThe research papers on the topic suggest the primary mode of attack to be a background tab attacking a sensitive tab also open. Does the recent Chrome change to limit processor usage of a background tab also neuter this attack vector?