[tbb-bugs] #30304 [Applications/Tor Browser]: Browser locale can be obtained via DTD strings

[Tor Bug Tracker & Wiki]

#30304: Browser locale can be obtained via DTD strings
--------------------------------------+--------------------------
 Reporter:  acat                      |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  High                      |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-fingerprinting        |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by acat):

 Here is a patch: https://github.com/acatarineu/tor-browser/commit/30304.

 https://github.com/acatarineu/tor-browser/commit/30304#diff-
 52beed12eac86326f289d0b43ffadb3bL215 should remove the exception that
 allows all DTDs to be loaded. In practice, removing this I think would
 only break legacy extensions. For example, it breaks `about:tor`, because
 its locale files are not contentaccessible and cannot be loaded anymore.

 With that change, contentaccessible=yes dtds can still be loaded from web
 content, and therefore still leaking browser language.
 https://github.com/acatarineu/tor-browser/commit/30304#diff-
 318b0aeb24e87bc216c590860a030b58R524 should fix that, forbidding any
 `chrome://*/locale/*` URIs to be loaded from web content,
 contentaccessible or not.

 This change breaks many `about:*` pages, since they rely on the locales
 being contentaccessible. The change here: https://github.com/acatarineu
 /tor-browser/commit/30304#diff-d637999733ba943ba8fc3b01c451df66R866 tries
 to fix that (and also previously mentioned about:tor breakage), allowing
 `about:*` pages to always load `chrome://*` resources.

 I'm making a couple of assumptions I would need to check. First, I'm
 assuming the only way to load locale DTDs is via `chrome://*/locale/*`. If
 there is a way to load them via `resource://*` or some `chrome` URIs that
 do not follow that structure, I think the patch would not work. Second,
 there is no way to load a resource from web content as `about:*`. If this
 was possible we could bypass the protection, because we are adding an
 exception for about pages.

 Then, there is breakage again. Since Firefox relies on several
 `resource://` and `chrome://` URIs to load in web content for some
 features, these changes might break something. I think #8725 and
 corresponding https://bugzilla.mozilla.org/show_bug.cgi?id=863246 are
 relevant here. Arthur mentions in bugzilla several features that use these
 (video controls, image display, text-box resizing, and directory listing).
 I checked this and they work with this patch in ESR60 (except text-box
 resizing, not sure which one is that).

 So I could not find this breaking in current ESR60. BUT, the same patch
 breaks several things in Firefox Nightly. First, the browser UI itself
 (for some reason it's loading `chrome://...` dtds from `moz-nullprincipal`
 origins). Video controls are also broken, displaying xml with errors
 (because the locale DTD could not be loaded).

 I think I'll update the bugzilla ticket with a patch for central (even if
 it's broken), and ni ckerschb as Tom suggested.

 A couple of tests: https://acatarineu.github.io/fp/locale.html
 https://acatarineu.github.io/fp/locale_nullprincipal.html.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30304#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online