5 ms·
I think this means we should consider all browser processes to be completely insecure, until mitigations are applied (e.g. Chrome's Site Isolation: https://www.
by theptip 9y ago
I think this means we should consider all browser processes to be completely insecure, until mitigations are applied (e.g. Chrome's Site Isolation: https://www.chromium.org/Home/chromium-security/ssca https://www.chromium.org/Home/chromium-security/ssca).
Looks like any session token/state could be exfiltrated from your Gmail tab to a malicious JS app running in-process, for example.
Am I overreacting here?
- kibwen 9y ago> Am I overreacting here? Still skimming the paper, but the JS attack appears to be processor-intensive (please chime in if you interpret it differently!). Any widespread, indiscriminate use of such an attack in the wild seems like it would eventually be detected as surely as client-side cryptocurrency mining was discovered. If you aren't a valuable target, if you don't visit sites that are shady enough to discreetly mine bitcoin in your browser, and if you use an adblocker to defang rogue advertisers, then you probably shouldn't lose too much sleep over this (which is not intended to diminish how awesome (in the biblical sense) this attack is). That said, if there were ever a time to consider installing NoScript, now's it: https://addons.mozilla.org/en-US/firefox/addon/noscript/ https://addons.mozilla.org/en-US/firefox/addon/noscript/
- jwilk 9y agoAnd if you're a web developer, now it the good moment to make sure your site works correctly when JS is disabled.
- thisacctforreal 9y agoYes please! Long live progressive enhancement and graceful degradation. At least until we get a JS interpreter with proper permission controls and sandbox limits. Something closer to how Lua is embedded sounds nice.
- deckard1 9y agoWe'll have to dig a time machine out and go back to 1998 then. I'm being a facetious ass. But you know I'm not wrong, either.
- dmm 9y agoYou are wrong. Install the NoScript extension and you can see your site without js. NoScript also allows you to selectively enable js per site on a temporary or permanent basis. This is the default way that I and many other people browse the web. https://noscript.net/ https://noscript.net/
- TikiTDO 9y agoJust looking around, general available figures for public internet (as opposed to tor) suggest that anywhere between 0.1% to 1.0% of users have JS disabled. These numbers have also been consistently going down over time. That's a fairly small number to dictate how a system should be designed.
- losteric 9y agoThat depends on your target demographic. JS is more frequently disabled among tech-literate customers, so a cloud provider's home page would probably benefit from working without JS.
- gatmne 9y ago> These numbers have also been consistently going down over time. That trend might reverse if vulnerabilities like these continue to surface.
- alkonaut 9y agoRight. It’s like designing for any other tiny group: color blind, blind, people who don’t read any of the 3 languages your site is already translated to, etc. I’m not saying that shouldn’t be done, but business wise its probably usually best to instead add design changes for the latest smartphone screen. The web isn’t a hypertext graph anymore, it’s a large JavaScript program with a thin html front now.
- drdrey 9y agoDoesn't each tab run in a separate process?
- kibwen 9y agoChrome starts putting multiple tabs in the same process once certain resource thresholds are reached. There's an experimental "site isolation" option that you can toggle on to enforce this better, currently with some caveats: https://www.chromium.org/Home/chromium-security/site-isolation#TOC-Known-Issues https://www.chromium.org/Home/chromium-security/site-isolati... . Curious to know whether Firefox has anything similar in the pipe, since it uses a fixed number of content processes rather than a variable number of processes.
- notriddle 9y agoYeah. https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan...
- theptip 9y agoThat's true to first approximation in Chrome, but apparently not always. This recent article contains a bit more detail on Site Isolation: https://arstechnica.com/gadgets/2017/12/chrome-63-offers-even-more-protection-from-malicious-sites-using-even-more-memory/ https://arstechnica.com/gadgets/2017/12/chrome-63-offers-eve... > Chrome's default model is, approximately, to use one process per tab. This more or less ensures that unrelated sites are kept in separate processes, but there are nuances to this set-up. Pages share a process if they are related through, for example, one opening another with JavaScript or iframes embedding (wherein one page is included as content within another page). Over the course of a single browsing session, one tab may be used to visit multiple different domains; they'll all potentially be opened within a single process. On top of this, if there are already too many Chrome processes running, Chrome will start opening new pages within existing processes, resulting in even unrelated pages sharing a process. Which suggests there are a number of cases where multiple tabs could share a process.
- 9y ago
- voidmain 9y agoIt seems like practical attacks rely on having a reasonably precise timer available. The spectre paper uses SharedArrayBuffer to synthesize a timer, which is a recent and obscure feature: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/dnzvgTswfbc https://groups.google.com/a/chromium.org/forum/#!topic/blink... https://groups.google.com/forum/#!topic/mozilla.dev.platform/Fjh9z7Er3aA https://groups.google.com/forum/#!topic/mozilla.dev.platform... Chrome and Firefox's "intent to ship" posts both contain claims to the effect that there probably aren't any really serious timing channel attacks, which... seems to have been disproved. Why isn't SharedArrayBuffer already being disabled as a stopgap? I think users can turn it off in firefox, how about Chrome?
- kibwen 9y ago> I think users can turn it off in firefox, how about Chrome? This month's stable Chrome release will be outright disabling SharedArrayBuffer until additional mitigations are enacted.
- londons_explore 9y agoWhich sucks for people who've built sites which rely on it. It isn't exactly polyfillable.
- erichurkman 9y agoThat shouldn't be that many sites. It only hit Chrome stable in July 2017; Firefox in August 2017; and Edge November 2017.
- olliej 9y agoI believe SAB is being disabled, and apparently precision of performance.now() as well? (based on other comments)
- caf 9y agoabout:config javascript.options.shared_memory in Firefox.