- tbb-dev - lists.torproject.org

Restarting nightly build
by Linus Nordberg 03 Apr '16

03 Apr '16

Hi Georg, FYI, I cleaned up some disk space on NORDUnet's build machine and restarted tonights continuous build which failed due to out of disk space.

1 0

New meeting time with daylight saving time in Europe -- 18:00 UTC
by Georg Koppen 22 Mar '16

22 Mar '16

Hi everyone, Starting with next Monday (March 28) we move our meeting time one hour back due to daylight saving times. The new meeting time will be 18:00 UTC. The place (as usual): #tor-dev on irc.oftc.net. See you there, Georg

1 0

window.localStorage and .sessionStorage deliberately broken for file:// URLs?
by dev942＠sigaint.org 03 Mar '16

03 Mar '16

I'm working on an application that's distributed as a single HTML file containing JavaScript, intended to be saved locally. The JavaScript then makes various XMLHttpRequests to the network, to provide security properties that a normal web application can't. That's kind of hacky (vs. doing it as a browser extension or whatever), but I was hoping that would make it easy to install in hardened, mostly-read-only OS installations. That works in stock Firefox. It doesn't work in Tor Browser, because window.localStorage (and .sessionStorage) fail for file:// URLs. Is that deliberate? They work for http:// and https:// URLs, so it doesn't seem like a security decision. Thanks.

2 1

Fwd: Address Sanitizer local root
by Tom Ritter 18 Feb '16

18 Feb '16

In case the tbb team hasn't seen this, I'm forwarding this email over. ---------- Forwarded message ---------- From: Szabolcs Nagy <nsz(a)port70.net> Date: 17 February 2016 at 16:19 Subject: [oss-security] Address Sanitizer local root To: oss-security(a)lists.openwall.com There is an alarming trend that Address Sanitizer and related compiler instrumentations from compiler-rt are used as a hardening solution and run in production. Even though these are debugging and testing tools, there is no clear warning against production use in their documentation: http://clang.llvm.org/docs/ And it's obvious how a tool that catches UB can be misunderstood as a hardening tool: This analysis concluded that ASan can be used for protection to stop certain attacks: http://scarybeastsecurity.blogspot.dk/2014/09/using-asan-as-protection.html The Tor project distributes ASan "hardened" binaries: https://blog.torproject.org/blog/tor-browser-55a4-hardened-released And there are various projects for full Linux distro instrumentation: http://balintreczey.hu/blog/progress-report-on-hardened1-linux-amd64-a-pote… https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with… (the later was presented at FOSDEM 2016: https://fosdem.org/2016/schedule/event/csafecode/ ) While these are interesting projects, ASan should not be used for hardening in production systems in its current form, so at least the language ("hardening", "protection", "safe") should be fixed. My simple local root exploit is that ASan uses a lot of environment variables without checking for secure execution of setuid binaries: ASAN_OPTIONS='verbosity=2 log_path=foo' ./suid.exe will write to foo.$PID using escalated priviledge, so a normal user may be able to clobber arbitrary root owned files (by creating foo.{1,2,3,..} symlinks to it) which can lead to local root on an "ASan hardened" Linux distribution: ASAN_OPTIONS='suppressions="/foo root:passwdhash:12345:0::::: bar" log_path=foo' ./suid.exe can easily clobber /etc/shadow with AddressSanitizer: failed to read suppressions file '/foo root:passwdhash:12345:0::::: bar' if there is any setuid root executable built with ASan. (This is not a problem for testing where the env var based configuration is convenient and I haven't checked if any of the current ASan distro efforts have setuid executables with instrumentation, but I still find it a security bug given the improper advertisment of the sanitizer tools: this can lead to problems if the documentation is not fixed.) Beyond this trivial issue there are plenty reliability problems in the sanitizer runtimes that i think deserve at least a warning. It can crash conforming applications because - the shadow map overlaps with something - ulimit -v - overcommit is turned off - it allocates memory but aborts on failure - it interposes __tls_get_addr with non-as-safe code. - it uses initial-exec TLS. - it handles "deadly" signals like SIGBUS (often used by applications using mmaped files). - the c runtime is updated and incompatible (with the various interposition hacks) - does not handle c11 thread creation some of the features reduce security: - heuristic introspective unwind - nice diagnositc messages at undefined behaviour - interpositions in general (UB according to POSIX) other limitations: - static linking is not supported (This is for ASan only, I briefly looked at thread sanitizer, which seemed even worse for reliability and safe stack that is in fact advertised for hardening but it has plenty reliability problems, needs further analysis.) I believe some of the problems can be fixed by implementing the runtimes in the libc instead of second guessing libc behaviour with fragile heuristics from a compiler runtime. This would solve most of the runtime aborts. I can see an easy way to do this with musl libc (because a non-host musl is easy to distribute and link against), but non-trivial with glibc. In either case I don't see a solution to the shadow map commit charge unless the kernel is modified. So I cannot recommend even a careful reimplementation in libc for production use for reliable systems.

1 0

Next meeting March 2, 19:00 UTC
by Georg Koppen 17 Feb '16

17 Feb '16

Hi, due to the developer meeting and folks being partly away from the keyboard next week we scheduled out next Tor Browser meeting on March 2 at 19:00 UTC either in #tor-dev or #tor-project on irc.oftc.net. Georg

1 0

missing status meeting
by Arthur D. Edelstein 15 Feb '16

15 Feb '16

Hi All, I will be missing the TBB-dev meeting on Monday due to a US holiday, but I will send a status report by email in the evening. Cheers, Arthur

4 5

38.6.0esr unit tests
by Nicolas Vigier 11 Feb '16

11 Feb '16

Hi, I have been rebasing the tor browser patches split repo on 38.6.0esr: https://github.com/boklm/gecko-dev/branches/all?utf8=%E2%9C%93&query=38.6.0… After submitting all branches to Try Server and ignoring the tests that already failed on 38.5.0esr, we have the following tests which failed: https://people.torproject.org/~boklm/try-results/2016-02-08_tor-browser-38.… The main things we can see is that we have a few tests that did not fail when they were run on 38.6.0esr without any other patch: - tbb-tests/test_tor_bug2875.html - tbb-tests/browser_tor_bug2950.js - tbb-tests/test_tor_bug4755.html - tbb-tests/test_tor_bug5856.html The other failures seems to be intermitent (some of them have been run twice and didn't fail the 2nd time, I will try to see if it's possible to ignore them automatically in that case), on a new branch (Bug-16620), or in the tor-browser branch (which includes the pref change patches, causing many test failures). The config used to filter results: https://people.torproject.org/~boklm/try-results/2016-02-08_tor-browser-38.… The full list of test results: https://people.torproject.org/~boklm/try-results/2016-02-08_tor-browser-38.… Nicolas

3 3

How does Tor Browser treat locally-installed CA cert?
by Linus Nordberg 28 Jan '16

28 Jan '16

Hi, As part of working on the CT Gossip draft [0] I find myself thinking about local trust anchors and how they might change browser behaviours. My understanding is that Tor Browser behaves like Firefox wrt locally added CA certs. If that's correct, do you know if FF treats pinning the way the "What Is HPKP For?" post [1] describes it? Another question that I find interesting is if TB could do better regarding fingerprintability based on what TLS session the browser accepts. [0] https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/ [1] https://noncombatant.org/2015/11/24/what-is-hpkp-for/

2 3

An Electrolysis-based approach for URL-bar domain isolation?
by Arthur D. Edelstein 05 Jan '16

05 Jan '16

Hi, everyone -- Happy New Year! I've been thinking about our work on first-party isolation in Tor Browser and I am wondering if Mozilla's Electrolysis project presents a new opportunity. Currently, we are using a number of isolation patches in Tor Browser: each patch prevents some browser feature (such the HTTP cache or DOM storage) from leaking information between URL bar domains. We're hoping that Mozilla will uplift these patches to mainline Firefox, but it's a very big task [1]. We have also disabled certain stateful features, including SSL Session IDs and TLS session tickets, SPDY, auto form-fill, third-party cookies and third-party HTTP authentication tokens. Disabling these features is straightforward, but somewhat degrades the browsing experience. Meanwhile, Mozilla has been pursuing the Electrolysis (e10s) project, aka Multiprocess Firefox [2]. The first iteration (already implemented and deployed in Aurora) separates the browser into two processes: one process for chrome and one process for all content. The content process is launched by the chrome process; they are both instances of the `firefox` executable. Mozilla says "In future iterations, we expect to have more than one content process." So, I'm thinking: could we use the Electrolysis mechanism to use a separate content process for each URL bar domain? In that case, any information in a given content process not explicitly shared with other processes or written to disk would be automatically isolated to the URL bar domain [3]. For example, there could be a separate in-memory cache in each content process. This approach might have several benefits. It might (a) let us drop most or all of our existing isolation patches (b) permit us to re-enable a number of stateful features, (c) protect against cross-origin tracking attacks we haven't discovered, and (d) allow us to easily implement a "New Identity for this Domain" menu item [4]. I also think Mozilla might find our privacy model easier to adopt if it were implemented this way. Any thoughts on this idea? Thanks, Arthur [1] Things for which we have already written patches for first-party isolation include the HTTP cache, the image cache, blob and media resource URLs, DOM storage, SharedWorkers, OCSP, favicons, and broadcast channels. We may also write further isolation patches for cookies, ServiceWorkers, and HSTS/HPKP, and likely other things. Dave Huseby at Mozilla is currently preparing the ground for attempting to uplift our patches. [2] https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox [3] Tor Browser already uses Private Browsing Mode and includes some additional settings and patches to try to prevent anything private from being written to disk. [4] "New Identify for this Domain", the content process would be shut down and re-started, with a new Tor circuit.

3 4

Next meeting on January 4 2016
by Georg Koppen 22 Dec '15

22 Dec '15

Hi, Yesterday we decided to skip the meeting on the next Monday (December 28) and start again with our weekly meeting schedule on January 4 2016. The time and place stays the same: 19:00 UTC in #tor-dev on irc.oftc.net. Georg

1 0