Introducing hardened builds for 64bit Linux
Hi, we are about to start a hardened Tor Browser series and the first nightly for it is ready to get tested (on 64bit Linux systems): https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly... https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly... Its major features are: 1) expensive hardening for tor (ASan, UBSan...) 2) ASan for the browser 3) the locales we ship/support are included in one bundle allowing to choose the locale for Tor Browser on start-up We plan to have something like 3) for the regular alpha and stable series in the (near) future as well. Thus, testing it and providing feedback is extra welcome. Georg P.S.: One bug I already found is related to the fact that the set of locales we include in the nightlies is not the same as Tor Launcher is assuming. Thus, 3) only works properly while choosing one of en-US, ar, ru, ja and zh-CN (and having the OS locale be one of them, too). This is bug 17399.
Georg Koppen:
Hi,
we are about to start a hardened Tor Browser series and the first nightly for it is ready to get tested (on 64bit Linux systems):
https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly... https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly...
Very nice! Are there any plans on a 32-bit Linux build soon? Nightly? We're quite interested trying this out in Tails which, sadly, only has a 32-bit user land (although it ships a 64-bit kernel, too). Any way I tried it briefly on Debian Jessie with much success: * Watching cats videos on YouTube in 720p without stuttering: Check! :) * Done! Seriously, though, I subjectively did notice some slowdowns on bloaty, ad-heavy sites (think: news papers). I guess that is to be expected. Also, when I exited I got: ASAN:SIGSEGV ================================================================= ==8134==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000000000 bp 0x7ff4e4eeeffa sp 0x7ffdad284918 T0) ==8134==Hint: pc points to the zero page. AddressSanitizer can not provide additional info. and then ~a minute of nothing with the process still running, and then: ASAN:SIGSEGV ==8294==AddressSanitizer: while reporting a bug found another one. Ignoring. and then ~another minute of nothing, and then the process exited (code = 1). I can reproduce this every time. Cheers!
anonym:
Georg Koppen:
Hi,
we are about to start a hardened Tor Browser series and the first nightly for it is ready to get tested (on 64bit Linux systems):
https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly... https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly...
Very nice!
Are there any plans on a 32-bit Linux build soon? Nightly? We're quite interested trying this out in Tails which, sadly, only has a 32-bit user land (although it ships a 64-bit kernel, too).
Not at the moment.
Any way I tried it briefly on Debian Jessie with much success:
Thanks!
* Watching cats videos on YouTube in 720p without stuttering: Check! :) * Done!
Seriously, though, I subjectively did notice some slowdowns on bloaty, ad-heavy sites (think: news papers). I guess that is to be expected. Also, when I exited I got:
ASAN:SIGSEGV ================================================================= ==8134==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000000000 bp 0x7ff4e4eeeffa sp 0x7ffdad284918 T0) ==8134==Hint: pc points to the zero page.
AddressSanitizer can not provide additional info.
and then ~a minute of nothing with the process still running, and then:
ASAN:SIGSEGV ==8294==AddressSanitizer: while reporting a bug found another one. Ignoring.
and then ~another minute of nothing, and then the process exited (code = 1). I can reproduce this every time.
Did you start the bundle via the start-tor-browser.desktop thing/the start-tor-browser script shipped with it or by other means? If the former any ideas on how to reproduce your crashes? Georg
Georg Koppen:
anonym:
Also, when I exited I got:
ASAN:SIGSEGV ================================================================= ==8134==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000000000 bp 0x7ff4e4eeeffa sp 0x7ffdad284918 T0) ==8134==Hint: pc points to the zero page.
AddressSanitizer can not provide additional info.
and then ~a minute of nothing with the process still running, and then:
ASAN:SIGSEGV ==8294==AddressSanitizer: while reporting a bug found another one. Ignoring.
and then ~another minute of nothing, and then the process exited (code = 1). I can reproduce this every time.
Did you start the bundle via the start-tor-browser.desktop thing/the start-tor-browser script shipped with it or by other means? If the former any ideas on how to reproduce your crashes?
To give a bit more context to my questions: I just tested the hardened bundle on a clean Debian Jessie on an old computer inside of VirtualBox and still it exited cleanly and without any big delay (it is working for me on Ubuntu 14.04 and Debian testing as well). I basically extract the bundle, cd into tor-browser and run |./start-tor-browser.desktop --debug --log| Georg
Georg Koppen:
Did you start the bundle via the start-tor-browser.desktop thing/the start-tor-browser script shipped with it or by other means? If the former any ideas on how to reproduce your crashes?
Sorry, I screwed up! I use a custom script that does basically the same, and while I did copy the ASAN_OPTIONS, I missed the exporting of that variable. With it exported, the error disappears. Sorry for the noise! Cheers!
Georg Koppen:
3) the locales we ship/support are included in one bundle allowing to choose the locale for Tor Browser on start-up
[...]
P.S.: One bug I already found is related to the fact that the set of locales we include in the nightlies is not the same as Tor Launcher is assuming. Thus, 3) only works properly while choosing one of en-US, ar, ru, ja and zh-CN (and having the OS locale be one of them, too). This is bug 17399.
I noticed a locale-related bug that will be relevant for Tails, but perhaps not the vanilla Tor Browser. Background: in Tails we will run the Tor Browser without Tor Launcher, and with intl.locale.matchOS = true so the locale that the user picked in our Greeter is used. So we won't have the language selection dialog, and the user can pick a locale that isn't available in that dialog. When an unsupported locale is used, about:tor is broken: XML Parsing Error: undefined entity Location: jar:file:///XXX/tor-browser/Browser/TorBrowser/Data/Browser/profile.default/extensions/torbutton@torproject.org.xpi!/chrome/content/aboutTor/aboutTor.xhtml Line Number 207, Column 3: <form action="&aboutTor.searchDCPost.link;" method="post"> --^ This happens, for instance, with these locales: export LANG="fi_FI.UTF-8" export LANG="fur_IT.UTF-8" export LANG="wx_YZ.UTF-8" So I'm not sure if this is somehow related to #17399 (or #17344). Should I report this as a new bug? Cheers!
Georg Koppen:
Hi,
we are about to start a hardened Tor Browser series and the first nightly for it is ready to get tested (on 64bit Linux systems):
https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly... https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly...
Its major features are:
1) expensive hardening for tor (ASan, UBSan...) 2) ASan for the browser 3) the locales we ship/support are included in one bundle allowing to choose the locale for Tor Browser on start-up
We plan to have something like 3) for the regular alpha and stable series in the (near) future as well. Thus, testing it and providing feedback is extra welcome.
Works well with my standard suite of tests. Does seem a little slow, though. I can't quantify it, but it "feels" slow. Using external apps with torsocks seems OK, so it's probably FF and not Tor. I'm seeing a lot (dozens) of these errors when using --debug: (firefox:675): GLib-GObject-WARNING **: /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3410: signal name 'text-remove::system' is invalid for instance '0x61d002479000' of type 'MaiAtkType27' (firefox:675): GLib-GObject-WARNING **: /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3410: signal name 'text-insert::system' is invalid for instance '0x61d002479000' of type 'MaiAtkType27' (firefox:675): GLib-GObject-WARNING **: /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3410: signal name 'text-remove::system' is invalid for instance '0x61d002f070a0' of type 'MaiAtkType27' Also seeing occasional: (firefox:675): GLib-GObject-WARNING **: /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3410: signal name 'text_selection_changed' is invalid for instance '0x61d002479000' of type 'MaiAtkType27' Running on Debian 8.2 -- kat
Katya Titov:
Georg Koppen:
Hi,
we are about to start a hardened Tor Browser series and the first nightly for it is ready to get tested (on 64bit Linux systems):
Works well with my standard suite of tests. Does seem a little slow, though. I can't quantify it, but it "feels" slow. Using external apps with torsocks seems OK, so it's probably FF and not Tor.
May be a memory leak. After sending the last email I saw that FF was using ~2GB of memory. Now, after running for 20 minutes and not using TBB at all, it is consuming ~1GB of memory and slowly growing. Running on Debian 8.2 -- kat
Katya Titov:
May be a memory leak. After sending the last email I saw that FF was using ~2GB of memory. Now, after running for 20 minutes and not using TBB at all, it is consuming ~1GB of memory and slowly growing.
Thanks. I tested a bit and the ASan build has a slowly growing memory consumption right from the beginning but only until it reaches ~1GB for me. Then it is stable (I compared that with recent ASan nightlies made by Mozilla and they are using ~1GB as well). This holds for just opening Tor Browser/Firefox. While opening web pages leads to a growing memory consumption I don't see ever-growing memory usage due to it. (Note, though, that the memory consumption of Tor Browser seems to be higher than the one visible with the Nightly. That might be due to Mozilla's ongoing efforts to shrink Firefox' memory usage or due to an underlying issue in our build.) Georg
On 10/21/2015 02:54 PM, Georg Koppen wrote:
Hi,
we are about to start a hardened Tor Browser series and the first nightly for it is ready to get tested (on 64bit Linux systems):
https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly... https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly...
Its major features are:
1) expensive hardening for tor (ASan, UBSan...) 2) ASan for the browser 3) the locales we ship/support are included in one bundle allowing to choose the locale for Tor Browser on start-up
We plan to have something like 3) for the regular alpha and stable series in the (near) future as well. Thus, testing it and providing feedback is extra welcome.
I experience a crash of Tor when I try to go to a new generated tor hidden service with just a default apache2 page from Debian Jessie. I run Debian Jessie: Linux boardsofcanada 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) x86_64 GNU/Linux This happens everytime when I try to go to this URL. Nov 01 00:12:30.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Nov 01 00:12:30.000 [notice] New control connection opened from 127.0.0.1. Nov 01 00:12:31.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Nov 01 00:12:31.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Nov 01 00:12:31.000 [notice] Bootstrapped 100%: Done console.error: [CustomizableUI] Custom widget with id loop-button does not return a valid node Nov 01 00:12:35.000 [notice] New control connection opened from 127.0.0.1. Nov 01 00:12:35.000 [notice] New control connection opened from 127.0.0.1. ================================================================= ==15963==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c0003fa4aa at pc 0x7f5804a9b94e bp 0x7ffcfe46a470 sp 0x7ffcfe46a468 READ of size 20 at 0x60c0003fa4aa thread T0 ASAN:SIGSEGV ==15963==AddressSanitizer: while reporting a bug found another one. Ignoring.
On 11/01/2015 12:25 AM, Jurre van Bergen wrote:
On 10/21/2015 02:54 PM, Georg Koppen wrote:
Hi,
we are about to start a hardened Tor Browser series and the first nightly for it is ready to get tested (on 64bit Linux systems):
https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly... https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly...
Its major features are:
1) expensive hardening for tor (ASan, UBSan...) 2) ASan for the browser 3) the locales we ship/support are included in one bundle allowing to choose the locale for Tor Browser on start-up
We plan to have something like 3) for the regular alpha and stable series in the (near) future as well. Thus, testing it and providing feedback is extra welcome.
I experience a crash of Tor when I try to go to a new generated tor hidden service with just a default apache2 page from Debian Jessie.
I run Debian Jessie: Linux boardsofcanada 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) x86_64 GNU/Linux
This happens everytime when I try to go to this URL.
Nov 01 00:12:30.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Nov 01 00:12:30.000 [notice] New control connection opened from 127.0.0.1. Nov 01 00:12:31.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Nov 01 00:12:31.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Nov 01 00:12:31.000 [notice] Bootstrapped 100%: Done console.error: [CustomizableUI] Custom widget with id loop-button does not return a valid node Nov 01 00:12:35.000 [notice] New control connection opened from 127.0.0.1. Nov 01 00:12:35.000 [notice] New control connection opened from 127.0.0.1. ================================================================= ==15963==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c0003fa4aa at pc 0x7f5804a9b94e bp 0x7ffcfe46a470 sp 0x7ffcfe46a468 READ of size 20 at 0x60c0003fa4aa thread T0 ASAN:SIGSEGV ==15963==AddressSanitizer: while reporting a bug found another one. Ignoring.
Same thing happens when I try to go to facebookcorewwwi.onion. I have attached my GDB output. Best, Jurre
participants (4)
-
anonym -
Georg Koppen -
Jurre van Bergen -
Katya Titov