TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Fantastic Timers: High-Resolution Microarchitectural Attacks in JS (2017) [pdf]

89 点作者 jhatax超过 7 年前

12 条评论

userbinator超过 7 年前
It&#x27;s apparently a pretty controversial position to have now, but I&#x27;ll say it again:<p>Leave JS off by default. Whitelist sites that absolutely need it. Running completely untrusted foreign code on your hardware has been, is, and likely will continue to be a source of security problems.<p>As a bonus, you get to enjoy much faster-loading, nearly ad-free and cruft-free pages on almost every site. Now couldn&#x27;t be a better time to try it out.
评论 #16083594 未加载
评论 #16082961 未加载
评论 #16083531 未加载
评论 #16083748 未加载
评论 #16082594 未加载
评论 #16082959 未加载
benjaminjackman超过 7 年前
Woah!<p>Summarizing:<p>...<p>Goethem et al. exploited more accurate in-browser timing to obtain information even from within other websites, such as contact lists or previous inputs.<p>...<p>Oren et al. recently demonstrated that cache side-channel attacks can also be performed in browsers. Their attack uses the performance.now method to obtain a timestamp whose resolution is in the range of nanoseconds. It allows spying on user activities but also building a covert channel with a process running on the system. Gruss et al. and Bosman et al. demonstrated Rowhammer attacks in JavaScript, leveraging the same timing interface. In response, the WC and browser vendors have changed the performance.now method to a resolution of 5 µs. The timestamps in the Tor browser are even more coarse-grained, at 100 ms .<p>In both cases, this successfully stops side-channel attacks by withholding necessary information from an adversary. In this paper, we demonstrate that reducing the resolution of timing information or even removing these interfaces is completely insucient as an attack mitigation.<p>...<p>Our key contributions are:<p>– We performed a comprehensive evaluation of known and new mechanisms to obtain timestamps. We compared methods on the major browsers on Windows, Linux and Mac OS X, as well as on Tor browser.<p>– Our new timing methods increase the resolution of ocial methods by 3 to 4 orders of magnitude on all browsers, and by 8 (!!) orders of magnitude on Tor browser. <i>Our evaluation therefore shows that reducing the resolution of timer interfaces does not mitigate any attack.</i><p>– We demonstrate the first DRAM-based side channel in JavaScript to exfiltrate data from a highly restricted execution environment inside a VM with no network interfaces.<p>– Our results underline that quick-fix mitigations are dangerous, as they can establish a false sense of security.
评论 #16082168 未加载
评论 #16081930 未加载
xigency超过 7 年前
Why high precision timing was ever introduced into browsers is beyond me. I don&#x27;t see why timers should be more accurate that millisecond precision or why the timer should return different values when polled more than once in the same execution context (as an event based language).<p>Edit:<p>&gt; Unlike other timing data available to JavaScript (for example Date.now), the timestamps returned by Performance.now() are not limited to one-millisecond resolution. Instead, they represent times as floating-point numbers with up to microsecond precision.<p>What a terrible idea. If this kind of profiling is needed, it should be better off as a feature of the browser developer tools, not a built-in function.<p>None of these examples are compelling to me either: <a href="https:&#x2F;&#x2F;w3c.github.io&#x2F;hr-time&#x2F;#introduction" rel="nofollow">https:&#x2F;&#x2F;w3c.github.io&#x2F;hr-time&#x2F;#introduction</a><p>HTML 5 audio has its own standards as does drawing. In fact, a high-precision timer is the worst solution to any of those problems.
评论 #16083121 未加载
评论 #16082854 未加载
feelin_googley超过 7 年前
Someone once suggested the risk in opening email attachments was analagous to the risk in running executable code (e.g., Javascript) from websites. Each can expose the user to a multitude of vulnerabilities. The argument against this comparison at the time was that Javascript from websites, unlike email attachments, could be run in a &quot;sandbox&quot;. Even if the code could not be trusted, it was &quot;safe&quot; because it was &quot;isolated&quot;.<p>Today, many users do not run Javascript because all too often it exposes them to excessive advertising and resource usage. Now, after researchers defeated KASLR with Javascript, and with Meltdown and Spectre being implemented in Javascript, there are additional benefits of not running third party Javascript.
nostoc超过 7 年前
That was extremely quick. Did they have this paper up their sleeve, expecting browsers to implement these kind of mitigation?
评论 #16084322 未加载
ezoe超过 7 年前
I was wondering how can I use SharedArrayBuffer to implement the high-resolution timer. It&#x27;s just consist of a dedicated thread keep incrementing the counter memory on SharedArrayBuffer. Read the counter value in SharedArrayBuffer from other threads and it&#x27;s effectively a high-resolution timer.<p>It can achieve 2 ns resolution.
cscheid超过 7 年前
So this paper appears to have been published on 2017-12-23 (according to <a href="https:&#x2F;&#x2F;link.springer.com&#x2F;chapter&#x2F;10.1007&#x2F;978-3-319-70972-7_13" rel="nofollow">https:&#x2F;&#x2F;link.springer.com&#x2F;chapter&#x2F;10.1007&#x2F;978-3-319-70972-7_...</a>), which was ahead of the Specter and Meltdown disclosures. Truly unfortunate timing for the browsers implementing mitigation, huh.<p>It seems that one of the covert channels described here has been fixed (SharedArrayBuffers) but many of the other ones have not. The passive reading of data from timing-based side effects (like CSS animation as described in the paper) seems particularly hard to avoid in general. HTML5 video will have the same vulnerability, I bet.
Analemma_超过 7 年前
I had a depressing feeling this was coming.<p>Are cache timing attacks just inherently impossible to stop? It’s sure starting to look that way with the last couple years of security research. Seems like every mitigation that gets thrown up is knocked down immediately.
评论 #16081838 未加载
评论 #16084436 未加载
评论 #16084215 未加载
_0w8t超过 7 年前
It is interesting that all security measures that Tor developers implemented gave them exactly nothing. The researches were able to get the same 2ns resolution as with stock Firefox.<p>I wonder if the measures in FF to counter the Spectre will fire any better.
dboreham超过 7 年前
I was wondering when we&#x27;d see a paper like this since I saw the post on Firefox reducing timer resolution. My immediate thought was &quot;there have to be other ways to get good enough timers to mount these attacks&quot;. Sure enough..
jnwatson超过 7 年前
Nice timing. This follows up well from my previous HN comment, that timers are everywhere. Pretty much any operation that has a small predictable time can be used as the basis for timing something else.
jhallenworld超过 7 年前
I&#x27;m pretty sure a timer on a webserver is going to be good enough to determine if an item is cached or not in the client. The time difference between cached and not-cached is huge.