28 ms·
Mitigations landing for new class of timing attack
- deleted 9y ago[deleted]
- ec109685 9y agoI wonder if this part of the reason why Google added Site Isolation as documented here: https://securityboulevard.com/2017/12/google-chrome-update-focuses-enterprise-security/ https://securityboulevard.com/2017/12/google-chrome-update-f...
- anonymfus 9y agoYes: https://support.google.com/faqs/answer/7622138#chrome https://support.google.com/faqs/answer/7622138#chrome
- MBCook 9y agoI read on Twitter earlier today that they were working on site isolation for six months before they found out about this. Certainly shows why it’s useful though.
- hirsin 9y agoNot 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)? I see over 100 pages of commits on github referencing it, which tells me it's not exactly rare?
- Game_Ender 9y agoHigh performance applications need to share memory between threads. That feature let you do it in JS, and is the basis of the future shared memory multithreading feature in Web Assembly. So if you want the next Photoshop or Final Cut Pro to be browser based we’ll need to make it work securely.
- ec109685 9y agoSeems like virtualization is the way to go for JavaScript. Hypervisors such as XEN in HVM mode with modern processors don’t result in a large performance penalty, so I imagine Chrome will gravitate towards it for running untrusted code.
- pcwalton 9y agoIf running JS (that can access the DOM) in a separate process from the renderer were feasible, browsers would have done it long ago.
- devit 9y agoYou just need to run it in a process without any secret data from other origins or the browser/system. That seems feasible without significant performance loss in most cases. There is still a fingerprinting issue though that might not be possible to fully remove without huge performance cost.
- contrarian_ 9y agoProcess isolation does not prevent Spectre. In theory, you can carry out Spectre over the network.
- pcwalton 9y agoThat's what Site Isolation is, but it has significant drawbacks: it cannot always protect against cross origin cookie leakage, and pages can have a lot more cross domain iframes than a reasonable process limit can account for.
- alangpierce 9y agoIt looks like SharedArrayBuffer was released in July 2017 in Chrome and August 2017 in Firefox [1], so I think it's new enough that almost any non-internal website using it would need a fallback anyway. So my impression is it's not quite as nuclear as other web technologies being disabled, but still pretty bad. I personally used it for a experimental hackathon project in April (in Chrome Canary, behind a flag), and I believe it was necessary for one of the aspects of the project, so it's a shame to see it disabled, but my impression is it's more "future web tech" than "the way the web works today". [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- userbinator 9y agoPerhaps high-resolution timing needs to be a permission and not a "right", just like access to location or webcam data.
- mulmen 9y agoCan the user be expected to make the right choice there? I have no problem deciding if Uber, a local restaurant or a news site need my location or camera data. I have no idea why they would need high precision timing data or even what "high precision" is. Maybe it's reasonable, maybe it isn't but it's not as easy to decide from the user's shoes as location/camera.
- discoursism 9y agoMost of the time, they won't need it. When they do, they'll need to make the case to you explicitly. Some phone apps currently do this when they need a non-obvious permission.
- kbsletten 9y agoI think that the point is that most users can't be expected to understand the risks present in allowing a high resolution timer. It's a very nuanced decision, unlike camera and storage and location.
- deleted 9y ago[deleted]
- jakozaur 9y agoSimple explanation: one of the attack is based on speculative out of order execution to access memory you don’t own. Though cpu cleans registry, it doesn’t clean up cache. So later through timing you can gain knowledge about something you shouldn’t know. That is why, reducing timers precision can help
- contrarian_ 9y agoIf it cleans cache, you can detect the evicted address tag.
- kbwt 9y ago> The resolution of performance.now() will be reduced to 20µs. 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.
- tanilama 9y agoI guess that is why they term it as mitigation, since they cannot fix it.
- discoursism 9y agoPresumably they are aware of this. If they reduce the data rate enough, the attack becomes less useful in practice. Presumably their engagements with security researchers and other browser vendors, along with internal experimentation, led them to believe that this resolution decrease offered significant mitigation.
- anonymfus 9y agoIf 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?
- simcop2387 9y agoThat's exactly what the shared buffer array thing is about. You can use a webworker to do exactly that and still get accurate enough timing to do accomplish this.
- geofft 9y agoAs I understand it, the only synchronous channel between browser-JS threads of any sort (workers, separate tabs/iframes) is a SharedArrayBuffer. Without that, you just have async things like postMessage or leaving notes for other threads in local storage / cookies / etc., so you can't read two different values from the counter within one timeslice without SharedArrayBuffers.
- Sephr 9y agoI warned about high accuracy SharedArrayBuffer-based timers on Hacker News[1] when Firefox and Chrome were adding SharedArrayBuffers. Glad to see people finally waking up to the fact that high accuracy timers are security vulnerabilities on most synchronous systems. 1. https://news.ycombinator.com/item?id=14057091 https://news.ycombinator.com/item?id=14057091
- fulafel 9y agoWhy is SAB different from other improvised clocks? Are other operations too slow?
- fpoling 9y agoThe other operations, like posting messages, have much higher latency noise. SAB allows to observe counter changes effectively within few CPU cycles with stable latency.
- mehrdadn 9y agoWould you know why people suddenly started worrying about this now, when—as you pointed out [1]—cache-based timing attacks in Javascript were already practical in 2015? What's so different about these cases now? Did the earlier research just fly under the radar? [1] https://news.ycombinator.com/item?id=14057224 https://news.ycombinator.com/item?id=14057224
- anon1385 9y agoAs far as I can tell there was basically a wink-wink nudge-nudge agreement between the various browser vendors/web standards authors (same people) that timing attacks that revealed things like the users browsing history, or that allowed tracking of users weren't a problem and not sufficient to block a feature from being added to browsers. See the many issues in [1][2][3][4][5] which stretch back over 6 years (and aren't all fixed) for an idea of how long this has been going on for (and a previous rant I wrote here https://news.ycombinator.com/item?id=10022315 https://news.ycombinator.com/item?id=10022315 ). The cache attacks never received as much publicity for some reason (the papers being harder to read may be one). I do wonder what would have happened if this hadn't come out at the same time as meltdown. It's quite possible it would have been brushed under the carpet yet again. There were token 'fixes' to these things (coarsening timers) in the past, but they never worked and everybody involved knew they wouldn't work. The introduction of features like SharedArrayBuffer revealed how (un)seriously they really took the problem. They knew it could be used to implement high precision timers but it got added to browsers anyway because it was central to the project of making the web an application platform. They perceive a need to allow high precision timers (or features that can be used to implement them) because without that the web won't be able to do a lot of things that are possible in native applications. I'd like to think that this is the moment that browser vendors come back to their senses and rethink what they are doing but I doubt it. Google is a multi billion dollar company based on the web as a platform, and running untrusted javascript on other peoples computers. Dropping the idea of the web as the platform to end all platforms would be an existential crisis for Mozilla. They are locked into this madness with no way to stop that wouldn't effectively be corporate suicide. Expect years of half hearted 'fixes' which don't fix the problem. [1] https://news.ycombinator.com/item?id=10455735 https://news.ycombinator.com/item?id=10455735 [2] https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07/09/DSN_paper.pdf https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07... [3] https://contextis.com/resources/white-papers/pixel-perfect-timing-attacks-with-html5 https://contextis.com/resources/white-papers/pixel-perfect-t... [4] https://www.mozilla.org/en-US/security/advisories/mfsa2013-55/ https://www.mozilla.org/en-US/security/advisories/mfsa2013-5... and https://bugzilla.mozilla.org/show_bug.cgi?id=711043 https://bugzilla.mozilla.org/show_bug.cgi?id=711043 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=884270 https://bugzilla.mozilla.org/show_bug.cgi?id=884270
- gpm 9y agoThis says > Specifically, in all release channels, starting with 57: Firefox 57 was released nov 14, did it already include those changes?
- H4CK3RM4N 9y agoI think that means it's been pushed to the release channel.
- rebelwebmaster 9y agoVersion 57.0.4 released a couple days ago contains the mitigations referenced in the post.
- thrillgore 9y agoSo what are the odds the NSA was aware of this?
- coolspot 9y ago146%
- deno 9y agoNo one can blame them for knowing… The real question is if Intel knew and were they in any way incentivised not to fix it sooner. It would be very “easy” to justify not fixing a bug that went undetected for let’s say 10 years… If there ever was NSA hardware bug this is how it would look like. I doubt we’ll ever know.
- Azeralthefallen 9y agoSo 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?
- oneweekwonder 9y agoThe feature was previously hidden behind a about:config option[0]. Not a ff user but might check if it is back and for now let your users now? Is chrome or edge affected? Should the SharedArrayBuffer mdn page be updated; or maybe moz://a will fix it quickly enough to allow it on by default again. By the looks of it, this will affect a lot of webgl code. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#compatNote_2 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- tedivm 9y agoChrome will be taking the same steps- > In line with other browsers, Chrome 64 will disable SharedArrayBuffer and modify the behaviour of other APIs such as performance.now, to help reduce the efficacy of speculative side-channel attacks. This is a temporary measure until other mitigations are in place. https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca https://sites.google.com/a/chromium.org/dev/Home/chromium-se...
- tkone 9y agoThe window.postMessage and related MessageChannel APIs. You have to set up a listener and then post a message across the "boundary" (like an iframe or webworker).
- alangpierce 9y agoThe phrasing in the post says "The SharedArrayBuffer feature is being disabled by default", so depending on your situation, you may be able to instruct your users to manually enable it, or you can at least enable it yourself to continue development in the meantime. Of course, that will likely be a browser-wide setting, so telling others to enable it will put them more at risk of these attacks. (As mentioned in another comment, the more robust solution is to use window.postMessage as a fallback, although it depends on exactly what you're doing.)
- microcolonel 9y agoAnd this is why running arbitrary software from people you've never heard of will always suck more.
- mrep 9y agoDoes anyone know how trustworthy client time accuracies are accounting for clock skews? 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/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. [0]: https://en.wikipedia.org/wiki/Cristian%27s_algorithm https://en.wikipedia.org/wiki/Cristian%27s_algorithm
- chrismorgan 9y agoThese timing attacks are all about local time deltas, not absolute times, because it’s measuring the CPU caches, not anything to do with the network. Things like “this operation took 5µs, which suggests that the data it was accessing was/was not cached”.
- rphlx 9y ago> we are disabling or reducing the precision of several time sources 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/high-res counters for which, in almost every case, they have no legitimate need. Perhaps future silicon should block direct access to the TSC & 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). 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. 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 not doing that. So kudos to the firefox team here and hopefully chrom[e|ium] quickly copies this.
- quotemstr 9y agoTimer coarsening is a bad idea. Turns out [1], a simple timer thread is a good enough poor man's cycle counter. What are you going to do: ban variables? Even if you could coarsen timers, adding random noise just makes attacks take longer. It doesn't make them impossible; attackers can just collect more measurements. You need to address the specific vulnerabilities, not shoot the clock_gettime messenger. [1] https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_lipp.pdf https://www.usenix.org/system/files/conference/usenixsecurit...
- deleted 9y ago[deleted]
- rphlx 9y ago> adding random noise just makes attacks take longer No. It's true that with a low-res clock source in some cases an attacker can still get the precise measurement they're after by repeating an operation 1000x+ more times. In some cases though that is not possible, because at that timescale the signal they're after is degraded by noise that they cannot predict or control: operating system interrupts, memory traffic from other threads, etc. Anyway, even if a lower-res clock source helps only 10% of the time, on defense you should always prefer to make an attack complicated, slow, partially-reliable rather than trivial, fast, highly-reliable. Developers who need a high-res clock source for profiling, etc, should of course still be able to enable one selectively. > You need to address the specific vulnerabilities, not shoot the clock_gettime messenger. You can and should do both, to gain some defense-in-depth against future attacks.
- deleted 9y ago[deleted]
- mehrdadn 9y agoShall we now have a new website permission for timers or at least high-precision timers? (It will be quite fun to get end-users to understand the ramifications of such a thing...)
- QasimK 9y agoI would strongly say no - while most users can immediately understand permissions to use the camera or microphone, understanding the permission for "high-precision timers" requires considerable unreasonable effort.
- zastrowm 9y agoHas there ever been discussion about a permission for "running as an app" that would make a distinction between web pages and apps? I like that the web gets more features that allow apps to run cross-platform, but I don't fully understand why we make no distinction between pages and apps.
- nachtigall 9y agoI wonder if and how Waterfox or Palemoon can keep up with these security issues? (Disclosure: I am a Firefox Nightly user)
- rebelwebmaster 9y agoThe performance.now() patch changed one line of code, so backporting that shouldn't be hard. The SharedArrayBuffer change is just flipping a pref, so that should be easy as well (assuming it's even supported - isn't Palemoon a pretty ancient fork of Firefox? Even Mozilla's most recent ESR release doesn't have SAB enabled by default).
- therealmarv 9y agoAnd Chrome? Do they do similar things NOW?
- stupidcar 9y agoYes https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca https://sites.google.com/a/chromium.org/dev/Home/chromium-se...
- deleted 9y ago[deleted]
- anon1385 9y agoMozilla 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: http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pdf http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pd... see the technique in section IV called time to tick (TTT): >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. >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. So, what stops this method from working, even with 20µs resolution performance.now()?
- tormeh 9y agoMaybe the clock can be made to drift? You can make the clock a random walk with the restriction that it never decreases, and doesn't deviate more than 20us? That is, each tick of the clock actually just adds a non-negative interval to the clock. Since the deviation from real time at tick depends on the deviation at tick-1 it would require more time to get good accuracy by averaging measurements.
- contrarian_ 9y agoRun it for long enough and you can average out the random drift. The issue cannot be fixed without disabling speculation entirely on current hardware.
- deleted 9y ago[deleted]
- contrarian_ 9y agoThis 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.
- deleted 9y ago[deleted]
- zerken 9y agoIs latest ESR version (52.5.3) of Firefox patched? I can't invoke SharedArrayBuffer for sure but what about the resolution of performance.now()?
- rebelwebmaster 9y agoThe performance.now() change is due to ship to ESR users with the 52.6 release on January 23.
- dmateos 9y agoIf you stack kernels like Hypervisor Guest OS Is there double the performance hit of all these attack fixes?
- masswerk 9y agoFor 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 ... E.g., (function() { var global = (function() { return this; }).call(), _Performance = global.Performance, _performance = global.performance; global.Performance = /* ... snip ... */; global.performance = /* ... snip ... */; })(); [Edit]: This could be injected by a browser-plugin on the user's side, as well.
- masswerk 9y agoNote: "May it be a wise idea ... ?" is an open question, meant to start a discussion. No need for down-voting, just answer or ignore it. :-)
- usernam 9y agoReducing the resolution coming from system timing sources is not going to stop attacks which have potentially infinite execution timelines. Limiting JS execution resources, and in particular CPU cycles, will actually stop instead a whole swath of timing and resource-dependent attacks. Please put your thought and chime into this thread: https://bugzilla.mozilla.org/show_bug.cgi?id=1414675 https://bugzilla.mozilla.org/show_bug.cgi?id=1414675 Allowing infinite resources for remote programs is something we don't even do for local programs. Giving a ceiling to the JS runtime is a sound reasoning. Please comment on the bug tracker!
- usernam 9y agoCommenting on the upstream bug tracker would do so much more than lazily clicking upvote.
- scottshea 9y agoI am very curious about Yehuda Katz's question on CSRF attacks and GET requests: https://twitter.com/wycats/status/948812652997885952 https://twitter.com/wycats/status/948812652997885952