Security: Recovering high-resolution timers to perform timing attacks
Reported by
clementi...@gmail.com,
Jan 25 2017
|
|||||||||||||||
Issue descriptionVULNERABILITY DETAILS Me and my co-authors are working on timing and micro-architectural attacks in browsers. These attacks need a high-resolution timer, which is not natively available since performance.now() has been reduced to 5us on Chrome. We investigated methods to recover a high resolution from performance.now() as well as to create new timers from the browser features. Expected result: there is no timer that has a better resolution than 5us. Actual result: there are several ways to get a timer with a resolution up to 15ns. Practically, in Chrome we found and evaluated (Table 1 in the attached document): - 2 methods to recover a high-resolution timer from performance.now(), including one that allowed us to recover a resolution of 15ns. The main issue comes from the fact that the original timer is only rounded down and not fuzzed in any way. - 6 features that can be used as a timer. Apart from the SharedArrayBuffer that has already been known to be able to recover a nanosecond resolution (and is not enabled by default), they have a resolution between 35us and 16ms. However, we can also use the two methods discussed above to recover a high resolution timer from them as well. VERSION Chrome Version: 53.0.2785.89 (64-bit) stable Operating System: Ubuntu 16.10 Note: all browsers tested to date have the similar issue. REPRODUCTION CASE We used this web page to perform our evaluation: https://misc0110.net/timings/ Related work: - http://www.cs.columbia.edu/~simha/spyjs.ccs15.pdf - https://cseweb.ucsd.edu/~hovav/papers/ks16.html
,
Jan 26 2017
,
Jan 30 2017
mseaborn, could you please help triage this? I'm not sure who the right people are to look at it.
,
Jan 30 2017
,
Jan 30 2017
,
Jan 30 2017
,
Jan 30 2017
,
Feb 8 2017
mseaborn: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 9 2017
Hi, I wanted to update you on our timeline: the article is to be published at the conference Financial Crypto, to be held in April. I hope this is not a problem with you, we can of course provide more details if you need.
,
Feb 22 2017
mseaborn: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 10 2017
,
Apr 20 2017
,
May 1 2017
I don't think there's much we can do for this issue.
The background to this paper is that access to high resolution timers allows various microarchitecture-based attacks, such as reading data via cache side channels or row hammering.
The point of the paper is that previous quick fixes weren't sufficient to prevent access to high resolution timers. The paper doesn't propose any new ways to restrict access to such timers. Their conclusion seems to be that we should give up on trying to restrict access to timers, and focus on mitigating the underlying microarch attacks ("As microarchitectural attacks are not restricted to JavaScript, we recommend to mitigate them at the system- or hardware-level").
But they don't discuss ways to mitigate microarch timing attacks, and I don't think there are currently any good ways to mitigate those, especially ways that Chrome is in a position to implement.
,
May 5 2017
Thanks Mark. I'm not sure how we should handle this then: if we cannot do anything about this it sounds like a WontFix?
,
May 5 2017
Sounds like it to me, but feel free to reopen if there are mitigations that seem worthwhile.
,
Aug 12 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by elawrence@chromium.org
, Jan 26 2017