Re: [tor-bugs] #21011 [Applications/Tor Browser Sandbox]: Disable JavaScript JIT

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#21011: Disable JavaScript JIT
----------------------------------------------+-------------------------
 Reporter:  cypherpunks                       |          Owner:  yawning
     Type:  enhancement                       |         Status:  new
 Priority:  Medium                            |      Milestone:
Component:  Applications/Tor Browser Sandbox  |        Version:
 Severity:  Normal                            |     Resolution:
 Keywords:  sandbox-security                  |  Actual Points:
Parent ID:                                    |         Points:
 Reviewer:                                    |        Sponsor:
----------------------------------------------+-------------------------

Comment (by cypherpunks):

 Replying to [comment:8 gk]:
 > As a general matter I think we should try to avoid dealing with browser
 related settings outside of the browser itself. For one it makes things
 harder to debug if there different pieces of our products are taking care
 of the same settings and we open up the whole system to subtle bugs that
 might lie in Mozilla's code (they might never have tested whether the
 parts we use play together nicely). Plus this mixing of responsibilities
 has the tendency to make the whole system harder to analyze.

 I don't see how it would do that. The interpreter is likely still used in
 many parts of the browser, and the same code is shared with the JIT
 compiler. I don't see how the interpreter could break without
 simultaneously breaking the JIT compiler and JITed code. Empirically, JIT
 causes far more bugs. The fact that they are often security related is why
 it's so problematic. I think the best thing to do would be to disable JIT
 on all security levels, for all version of Tor Browser, sandboxed or not.

 > For now, having the slider set to "High" in the alpha Tor Browser
 sandbox is okay with me but we should think harder about that if we
 envision a future (as I do) where we only ship Tor Browser in the sandbox
 to our users. Maybe that's some kind of crazy Utopia but I want to see all
 users benefiting from the security guarantees the sandbox provides. And
 currently it seems to me we would drive quite a chunk of them away with
 that move. A lot of the web is broken in that mode (alas) and users will
 not blame Facebook or whomever for that but Tor Browser and choose a
 different (albeit less secure by default) product.

 Disabling JIT would provide security benefits to JavaScript users without
 breaking Facebook and other sites. It's just a performance optimization
 which doesn't provide new functionality, after all. As for having the
 default set to high, to me at least that seems more like a feature which
 will not be present if the sandbox is added to the default browser. Or at
 least, not used at the default security setting. But considering the
 sandbox is, at the moment, only used by people who manually install it
 because they specifically want high security, setting the default to high
 seems reasonable.

 > Regarding messing with the JIT preferences: what I said above in the
 first paragraph applies here as well + I feel we need to be careful to not
 introduce ways to fingerprint users of the Tor Browser sandbox that way. I
 am  not sure whether flipping those prefs would already be bad. But I
 could imagine that some timing measurements might be able to reveal them,
 in combination with all the other prefs set on your particular slider
 mode. (Sure, if you have set your slider level to "High" this would be
 moot but then flipping those prefs in then first place would be
 superfluous as well)

 The sandbox is already trivial to fingerprint. I didn't think that was
 even a question. I can think of a few possibilities:

 * It blocks notoriously insecure libraries like gstreamer which default
 installs already have for instance, in order to reduce attack surface
 area. I wouldn't be surprised if more libraries are blocked. This
 completely disables support for certain media codecs, which an attacker
 can tell if you use media (though it does mean that it'll no longer be a
 piece of cake to exploit you through said media, even if ffmpeg is still
 around).
 * The proc filesystem is not mounted so system information (like memory
 usage) is not accessible. I wouldn't be surprised if there is a way to
 trigger behavior in Firefox that only occurs when it cannot access the
 directory.
 * You could likely trigger a sandbox violation if you tried hard enough,
 leading to a crash from a fatal signal or an internal error. Good luck
 writing a good seccomp sandbox for a huge program with two dozen libraries
 if your threat model includes "don't let anyone who wants to know if the
 sandbox is in use trigger a syscall violation".
 * Having hardware acceleration disabled by blocking access to the render
 nodes is also fingerprintable (not that the render nodes themselves don't
 also provide a powerful fingerprinting vector).
 * Reduced performance, through disabled JIT as you mentioned or through
 replacing high-performance vDSO calls with regular syscalls (necessary to
 disable CR4.TSD to mitigated timing attacks) as planned in another ticket.
 * There might also be a way to trigger an intentional priority inversion
 in pulseaudio through Firefox so the priority-inheritance futex-disabling
 patches cause the browser to lock up (not that I can think of a way to do
 this, but I can't say it's impossible either).

 Of course, simply having JavaScript enabled would cause far worse
 fingerprinting (audio context fingerprinting, math library fingerprinting,
 performance fingerprinting, clock skew fingerprinting, all the forms of
 GPU fingerprinting, battery API fingerprinting, security slider
 fingerprinting, HID fingerprinting, the list goes on). So I think the
 general idea should be that a user of the sandbox should not use
 JavaScript unless they want sandbox fingerprinting to be added to that
 list.

 Personally, I think the highest security level for the sandbox should even
 disable JavaScript in the config entirely, since we know that NoScript
 bypasses exist, and I've heard of the existence of extant ones from
 several different places (not to mention @movrcx, if that counts), whereas
 bypassing a disabled config entry would seem to be next to impossible. But
 that's for another ticket and more thought, considering it would disable
 pdf.js (whether or not that'd necessarily be a bad thing for a sandbox on
 its maximum setting, I don't know...).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21011#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs