asm.js files should be no linkability risk
#19400 (moved) revealed that asm.js files are cached to disk which violates at least our no-disk-leaks requirement. The upstream bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1047105 which got fixed in Firefox 51. However, there are linkability risks as well we might want to address.
Activity
It's even worse than just tbb-disk-leak because it's not cleared by New Identity like #18589 (moved) does. (tbb-newnym?)
bug_19417 (https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_19417) has a fix up for review that takes New Identity into account and blows the whole storage away during start-up (in case the user specified the no-disk option which is the default one).
Trac:
Status: new to needs_review
Keywords: N/A deleted, GeorgKoppen201606, TorBrowserTeam201606R added-
After thinking about it more it seems to me there is the additional risk that this mechanism could be used to embed supercookies. Like, deliver JS to a user that contains an identifier -> get that into the asmjscache -> once this is loaded anywhere ping the identifier back.
Looking at https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/ does not rule that scenario out:
The cache entry is keyed on: the origin of the script, the source characters of the asm.js module, the type of CPU and its features, the Firefox build-id (which changes on every major or minor release).Note this would be especially problematic for Tor Browser users as we are currently not changing the build-id.
Not sure what "the origin of the script" means but I doubt "URL bar domain". It could mean as well that the asmjs cache is not caring about starting SOP either.
Reading between the lines on that blog post it appears to me that there is indeed a way to disable this whole caching mechanism with:
javascript.options.parallel_parsingset tofalse. It's worth investigating this closer I think.Trac:
Summary: asm.js files should not be cached to disk in Tor Browser to asm.js files should not be cached to disk in Tor Browser and no linkability risk
Cc: mcs, brade to mcs, brade, arthuredelstein
Description: #19400 (moved) revealed that asm.js files are cached to disk which violates our no-disk-leaks requirement. The upstream bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1047105.to
#19400 (moved) revealed that asm.js files are cached to disk which violates at least our no-disk-leaks requirement. The upstream bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1047105.
Keywords: N/A deleted, tbb-linkability added 
Replying to gk:
After thinking about it more it seems to me there is the additional risk that this mechanism could be used to embed supercookies. Like, deliver JS to a user that contains an identifier -> get that into the asmjscache -> once this is loaded anywhere ping the identifier back.
Looking at https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/ does not rule that scenario out: {{{ The cache entry is keyed on: the origin of the script, the source characters of the asm.js module, the type of CPU and its features, the Firefox build-id (which changes on every major or minor release). }}} Note this would be especially problematic for Tor Browser users as we are currently not changing the build-id.
Not sure what "the origin of the script" means but I doubt "URL bar domain". It could mean as well that the asmjs cache is not caring about starting SOP either.
They do use principals in the asmjscache code, so maybe there is some protection (not enough for us though).
Are you now thinking that we should unconditionally disable the asmjscache?
I spent a little time trying to figure out how to cleanly disable the cache when in private browsing mode (I was hoping progress would be reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1047105 but that has not happened so far).
For web workers, it might work to avoid calling JS::SetAsmJSCacheOps() inside dom/workers/RuntimeService.cpp when in private browsing mode.
For content windows, I think we could make changes inside dom/base/nsJSEnvironment.cpp to ensure that AsmJSCacheOpenEntryForRead() and AsmJSCacheOpenEntryForWrite() do nothing when operating inside a private browsing mode window.
-
Replying to mcs:
Replying to gk:
After thinking about it more it seems to me there is the additional risk that this mechanism could be used to embed supercookies. Like, deliver JS to a user that contains an identifier -> get that into the asmjscache -> once this is loaded anywhere ping the identifier back.
Looking at https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/ does not rule that scenario out: {{{ The cache entry is keyed on: the origin of the script, the source characters of the asm.js module, the type of CPU and its features, the Firefox build-id (which changes on every major or minor release). }}} Note this would be especially problematic for Tor Browser users as we are currently not changing the build-id.
Not sure what "the origin of the script" means but I doubt "URL bar domain". It could mean as well that the asmjs cache is not caring about starting SOP either.
They do use principals in the asmjscache code, so maybe there is some protection (not enough for us though).
Are you now thinking that we should unconditionally disable the asmjscache?
Well, doing so with
javascript.options.parallel_parsingset tofalsedoes not work at least. :) What to do depends on how serious the issue is. If there are no linkability issues then making it just obey PBM is fine with me. If it can get used to track users across sites then we might want to disable it first and then enable it successively as soon as this is fixed.I actually tried to find proper sites that could be loaded in an iframe AND would exhibit asmjscaching but I failed so far. Seeing what is happening on the user's disk in this case might actually be revealing. Who knows what "origin if the script" boils down to given that nobody was caring about user privacy much in this case anyway.
I spent a little time trying to figure out how to cleanly disable the cache when in private browsing mode (I was hoping progress would be reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1047105 but that has not happened so far).
For web workers, it might work to avoid calling JS::SetAsmJSCacheOps() inside dom/workers/RuntimeService.cpp when in private browsing mode.
For content windows, I think we could make changes inside dom/base/nsJSEnvironment.cpp to ensure that AsmJSCacheOpenEntryForRead() and AsmJSCacheOpenEntryForWrite() do nothing when operating inside a private browsing mode window.
Seems to be worth a try to me.
-
Okay. Running the asm.js benchmark in https://people.torproject.org/~gk/misc/asmjscache_iframe.html generates a cache entry that is keyed to
https+++kripken.github.iowhich happens as well if I run the test directly on the site. -
Replying to cypherpunks:
I assume simply disabling asm.js (by setting javascript.options.asmjs to false) is not an option here?
It is one and I think we are going to do that as a stopgap solution.
Note that this bug appears to be the root cause of #19657 (moved), triggering a crash/ASan.
Trac:
Keywords: N/A deleted, tbb-crash added-
Let's leave
tbb-crashfor #19400 (moved). This ticket is concerned with the cache and linkability issue.Trac:
Keywords: tbb-crash deleted, N/A added -
Okay, bug_19417_v2 (https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_19417_v2) in my Torbutton repo and bug_19417 in my tor-browser repo (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_19417) are up for review.
Trac:
Status: assigned to needs_review
Keywords: TorBrowserTeam201607 deleted, TorBrowserTeam201607R added -
Applied to torbutton (master and maint-1.9.5) as commit 621916d0f79336b95d7390c2e30e2c81c0d2a504 and 48252096e210b78ab56a5623b296301929faea9f and to tor-borwser (tor-browser-45.2.0esr-6.5-1 and tor-browser-45.2.0esr-6.0-1) as commit 699ae74066ddc7000a3ea5f4ed68b170d1886065 and 9f49b80ab4a5c2326ca47f0736d0b865fa2272f9.
Trac:
Status: needs_review to assigned
Keywords: TorBrowserTeam201607R deleted, TorBrowserTeam201607 added Replying to gk:
Let's leave
tbb-crashfor #19400 (moved). This ticket is concerned with the cache and linkability issue. Are you going to file another ticket fortbb-newnymissue?(Hmm, from your changelog: Disable asm.js (but add code to clear on New Identity if enabled) - newnym fix advertised (disk only?))
-
We should backport https://hg.mozilla.org/mozilla-central/rev/07979189c602 and let asmjs be governed by the slider again. I think we can keep the
NEWNYMhandling, though.Trac:
Keywords: GeorgKoppen201606, TorBrowserTeam201607 deleted, GeorgKoppen201609, TorBrowserTeam201609 added -
bug_19417_v2 in my tor-browser repo has the fixes we need to apply to the browser part (the backport of Mozilla's patch and not disabling asmjs anymore):
https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_19417_v2&id=ecdfc89579b6a403beda082c536a1d0b960363f5 https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_19417_v2&id=7af178793a20483896cd657fa06bb6ddc587b3a8
bug_19417_v4 in my torbutton repo puts the pref under the rule of the security slider again:
Please review (especially the patch backport).
Trac:
Status: assigned to needs_review
Keywords: TorBrowserTeam201609 deleted, TorBrowserTeam201609R added -
ESR 52 should have the patches for the caching. We should revisit this ticket when switching, especially as problems without asmjs show up (see #21298 (moved)).
Trac:
Keywords: N/A deleted, ff52-esr added -
Replying to legind:
Here's a friendly ping to revisit this issue, now that the transition to 52 is complete.
So, the disk leak is gone but there is still the problem of asmjs not adhering to our URL bar domain isolation. This part still needs to be investigated. I am adjusting the title and description of the ticket.
WebAssembly is a related upcoming standard in development at W3C, we should also keep an eye on this as well.
That's true. FWIW wasm got disabled by Mozilla in the ESR 52 series, though. We have #21549 (moved) for the investigation task.
Trac:
Status: needs_revision to assigned
Summary: asm.js files should not be cached to disk in Tor Browser and no linkability risk to asm.js files should be no linkability risk
Keywords: tbb-disk-leak deleted, N/A added
Description: #19400 (moved) revealed that asm.js files are cached to disk which violates at least our no-disk-leaks requirement. The upstream bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1047105.to
#19400 (moved) revealed that asm.js files are cached to disk which violates at least our no-disk-leaks requirement. The upstream bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1047105 which got fixed in Firefox 51. However, there are linkability risks as well we might want to address.
-
Replying to gk:
Replying to legind:
Here's a friendly ping to revisit this issue, now that the transition to 52 is complete.
So, the disk leak is gone but there is still the problem of asmjs not adhering to our URL bar domain isolation. This part still needs to be investigated. I am adjusting the title and description of the ticket.
Actually, asm.js should be governed by the QuotaManager which in turn should take care of FPI. We should double-check that and, if it is indeed true, put it again into our security slider-treatment.
Trac:
Keywords: N/A deleted, TorBrowserTeam201802 added The asm.js caching was removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1520931. Should we revisit this and try to enable asm.js for esr68? We should be able to remove
Services.qms.clear()in torbutton and revert #31396 (moved).Trac:
Keywords: ff52-esr deleted, ff68-esr added-
Replying to acat:
The asm.js caching was removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1520931. Should we revisit this and try to enable asm.js for esr68? We should be able to remove
Services.qms.clear()in torbutton and revert #31396 (moved).Sounds good. Please do, if you want. How does it work then, though, if you have PBM disabled? Is everything happening on the fly, in memory, or...? We should investigate the FPI concerns here, too. See: comment:32
Trac:
Keywords: TorBrowserTeam201805 deleted, TorBrowserTeam201909 added I do not see any asm.js cache, disk or in-memory.
It's not a strong proof, but I did a quick test with https://kripken.github.io/Massive/ (there are console logs with asm.js compilation time). Testing with Firefox 64, where caching was still enabled, shows that for cached asm.js loading time is much faster (like 50ms vs 1000ms). In 68 there is no difference in times, either in PBM or "persisting" mode.
Regarding comment:32, if the disk leak was solved (in https://bugzilla.mozilla.org/show_bug.cgi?id=1047105), what were the FPI concerns back then? Was there an in-memory cache that did not respect FPI?
-
Replying to acat:
I do not see any asm.js cache, disk or in-memory.
It's not a strong proof, but I did a quick test with https://kripken.github.io/Massive/ (there are console logs with asm.js compilation time). Testing with Firefox 64, where caching was still enabled, shows that for cached asm.js loading time is much faster (like 50ms vs 1000ms). In 68 there is no difference in times, either in PBM or "persisting" mode.
Regarding comment:32, if the disk leak was solved (in https://bugzilla.mozilla.org/show_bug.cgi?id=1047105), what were the FPI concerns back then? Was there an in-memory cache that did not respect FPI?
Well, it was not really solved as you would get the problem again when not being in PBM. If there is no in-memory cache (anymore), good. So asm.js files are just loaded on the fly and executed? If there is no storage involved and no identifier read-back/extraction over domains, great. Then we are done with the FPI concern. If we enable it again we should make sure it's disabled on safer and safest levels, though, I think (as it was before).
For review: https://github.com/acatarineu/tor-browser/commit/19417 and https://github.com/acatarineu/torbutton/commit/19417
Trac:
Keywords: TorBrowserTeam201910 deleted, TorBrowserTeam201910R added
Status: assigned to needs_reviewRevised: https://github.com/acatarineu/torbutton/commit/19417+1.
Trac:
Keywords: GeorgKoppen201609 deleted, GeorgKoppen201610R added
Status: needs_revision to needs_review
