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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Mitigations landing for new class of timing attack

483 点作者 Nrbelex超过 7 年前

23 条评论

rphlx超过 7 年前
&gt; we are disabling or reducing the precision of several time sources<p>I am really happy to see this happening at long last. One can argue that almost every x86 SW side channel attack (Spectre and many prior ones that, for instance, leak parts of cryptographic keys from variable-time SW implementations) are being aided by userspace processes having access to high-frequency&#x2F;high-res counters for which, in almost every case, they have no legitimate need. Perhaps future silicon should block direct access to the TSC &amp; friends, except for processes that have a privileged flag set (hardly a new idea; IIRC some IBM PowerPC chips from the late 90s support that).<p>OS-level timing calls such as gettimeofday() could be degraded to a few microseconds resolution by default - poor enough to obscure delays caused by the state of various HW caches, branch predictors, etc.<p>Ultimately there is little reason to give every website js program access to a nanosecond-level counter by default, and many defense-in-depth reasons for <i>not</i> doing that. So kudos to the firefox team here and hopefully chrom[e|ium] quickly copies this.
评论 #16068477 未加载
评论 #16068631 未加载
评论 #16068637 未加载
评论 #16068521 未加载
评论 #16068988 未加载
评论 #16069758 未加载
评论 #16068723 未加载
评论 #16068797 未加载
评论 #16070151 未加载
Sephr超过 7 年前
I warned about high accuracy SharedArrayBuffer-based timers on Hacker News[1] when Firefox and Chrome were adding SharedArrayBuffers.<p>Glad to see people finally waking up to the fact that high accuracy timers are security vulnerabilities on most synchronous systems.<p>1. <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14057091" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14057091</a>
评论 #16068416 未加载
评论 #16069176 未加载
anon1385超过 7 年前
Mozilla previously reduced the precision of performance.now() to 5µs. This was trivially defeated by just running performance.now() in a tight loop, as described here: <a href="http:&#x2F;&#x2F;www.cs.vu.nl&#x2F;&#x2F;~herbertb&#x2F;download&#x2F;papers&#x2F;anc_ndss17.pdf" rel="nofollow">http:&#x2F;&#x2F;www.cs.vu.nl&#x2F;&#x2F;~herbertb&#x2F;download&#x2F;papers&#x2F;anc_ndss17.pd...</a> see the technique in section IV called time to tick (TTT):<p>&gt;The idea behind the TTT measurement, as shown in Figure 4.4, is quite simple. Instead of measuring how long a memory reference takes with the timer (which is no longer possible), we count how long it takes for the timer to tick after the memory reference takes place. More precisely, we first wait for performance.now() to tick, we then execute the memory reference, and then count by executing performance.now() in a loop until it ticks. If memory reference is a fast cache access, we have time to count more until the next tick in comparison to a memory reference that needs to be satisfied through main memory.<p>&gt;TTT performs well in situations where performance.now() does not have jitter and ticks at regular intervals such as in Firefox. We, however, believe that TTT can also be used in performance.now() with jitter as long as it does not drift, but it will require a higher number of measurements to combat jitter.<p>So, what stops this method from working, even with 20µs resolution performance.now()?
评论 #16069592 未加载
kbwt超过 7 年前
&gt; The resolution of performance.now() will be reduced to 20µs.<p>That will reduce the data rate of this particular covert channel, not prevent the attack altogether. Even adding random noise would not rule out the attack.
评论 #16067596 未加载
评论 #16067595 未加载
usernam超过 7 年前
Reducing the resolution coming from system timing sources is not going to stop attacks which have potentially infinite execution timelines.<p>Limiting JS execution resources, and in particular CPU cycles, will actually stop instead a whole swath of timing and resource-dependent attacks.<p>Please put your thought and chime into this thread:<p><a href="https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1414675" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=1414675</a><p>Allowing infinite resources for remote programs is something we don&#x27;t even do for <i>local</i> programs. Giving a ceiling to the JS runtime is a <i>sound</i> reasoning.<p>Please comment on the bug tracker!
评论 #16085538 未加载
Azeralthefallen超过 7 年前
So a quick question. What is the alternative to SharedArrayBuffer? One of the web applications i work on use it a fair amount. Is our app now just going to break?
评论 #16071584 未加载
评论 #16068701 未加载
评论 #16070787 未加载
userbinator超过 7 年前
Perhaps high-resolution timing needs to be a permission and not a &quot;right&quot;, just like access to location or webcam data.
评论 #16067574 未加载
评论 #16067729 未加载
评论 #16067638 未加载
contrarian_超过 7 年前
This is basically an arms race. As long as the fundamental issue is not fixed and all silicon replaced, there will always be people coming up with new ways of exploiting the Spectre vulnerability in unexpected ways.
mehrdadn超过 7 年前
Shall we now have a new website permission for timers or at least high-precision timers? (It will be <i>quite</i> fun to get end-users to understand the ramifications of such a thing...)
评论 #16071543 未加载
评论 #16069290 未加载
ec109685超过 7 年前
I wonder if this part of the reason why Google added Site Isolation as documented here: <a href="https:&#x2F;&#x2F;securityboulevard.com&#x2F;2017&#x2F;12&#x2F;google-chrome-update-focuses-enterprise-security&#x2F;" rel="nofollow">https:&#x2F;&#x2F;securityboulevard.com&#x2F;2017&#x2F;12&#x2F;google-chrome-update-f...</a>
评论 #16067578 未加载
anonymfus超过 7 年前
If instead of measuring time directly attacker would try to increment a counter in a loop in another thread, would they get enough accuracy and precision for the attack to work?
评论 #16067675 未加载
评论 #16067693 未加载
hirsin超过 7 年前
Not being familiar with the usage of SharedArrayBuffer, is disabling it the nuclear option (eg bad for everyone involved and clearly not the best option if others existed)?<p>I see over 100 pages of commits on github referencing it, which tells me it&#x27;s not exactly rare?
评论 #16068293 未加载
评论 #16067554 未加载
scottshea超过 7 年前
I am very curious about Yehuda Katz&#x27;s question on CSRF attacks and GET requests: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;wycats&#x2F;status&#x2F;948812652997885952" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;wycats&#x2F;status&#x2F;948812652997885952</a>
mrep超过 7 年前
Does anyone know how trustworthy client time accuracies are accounting for clock skews?<p>After a bunch of google searches, I have not found anything suggesting how accurate clocks are for clients besides Charlies algorithm [0] (I want to know UTC time&#x2F;epoch... whatever from each client so i can compare them) which I am concerned about adopting due to the wiki page assuming a high quality network.<p>[0]: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Cristian%27s_algorithm" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Cristian%27s_algorithm</a>
评论 #16068378 未加载
gpm超过 7 年前
This says<p>&gt; Specifically, in all release channels, starting with 57:<p>Firefox 57 was released nov 14, did it already include those changes?
评论 #16067871 未加载
评论 #16086434 未加载
jakozaur超过 7 年前
Simple explanation: one of the attack is based on speculative out of order execution to access memory you don’t own.<p>Though cpu cleans registry, it doesn’t clean up cache. So later through timing you can gain knowledge about something you shouldn’t know.<p>That is why, reducing timers precision can help
评论 #16070238 未加载
thrillgore超过 7 年前
So what are the odds the NSA was aware of this?
评论 #16070649 未加载
评论 #16068503 未加载
nachtigall超过 7 年前
I wonder if and how Waterfox or Palemoon can keep up with these security issues? (Disclosure: I am a Firefox Nightly user)
评论 #16086454 未加载
therealmarv超过 7 年前
And Chrome? Do they do similar things NOW?
评论 #16068896 未加载
评论 #16068916 未加载
dmateos超过 7 年前
If you stack kernels like<p>Hypervisor Guest OS<p>Is there double the performance hit of all these attack fixes?
microcolonel超过 7 年前
And this is why running arbitrary software from people you&#x27;ve never heard of will <i>always</i> suck more.
zerken超过 7 年前
Is latest ESR version (52.5.3) of Firefox patched?<p>I can&#x27;t invoke SharedArrayBuffer for sure but what about the resolution of performance.now()?
评论 #16086464 未加载
masswerk超过 7 年前
For the interim, may it be a wise idea to include an inlined script at the very top of any page which includes untrusted 3rd party code, in order to overwrite the Performance tools by a wrapper? By adding some random to the real numbers this may help mitigating effects ...<p>E.g.,<p><pre><code> (function() { var global = (function() { return this; }).call(), _Performance = global.Performance, _performance = global.performance; global.Performance = &#x2F;* ... snip ... *&#x2F;; global.performance = &#x2F;* ... snip ... *&#x2F;; })(); </code></pre> [Edit]: This could be injected by a browser-plugin on the user&#x27;s side, as well.
评论 #16071847 未加载