Selfrando: Q and A with Georg Koppen

Georg Koppen is a longtime Tor browser developer. He and Tor developer Mike Perry worked to integrate Selfrando into Tor browser.

Tell us about Selfrando, the new code being tested for Tor Browser.

Selfrando randomizes Tor browser code to ensure that an attacker doesn't know where the code is on your computer. This makes it much harder for someone to construct a reliable attack--and harder for them to use a flaw in your Tor Browser to de-anonymize you. 

How were you and Tor's Mike Perry involved in the project?  

We mainly worked on integrating Selfrando in Tor Browser where needed and tested it as well as we could. We closely read the paper and helped to improve it. The bulk of the work was done by the other researchers. These are Mauro Conti, Stephen Crane, Tommaso Frassetto, Andrei Homescu, Per Larsen, Christopher Liebchen, and Ahmad-Reza Sadeghi.

Can you talk about Tor's relationship with the research community?

Tor relies on the research community to ethically investigate unsolved issues with Tor software. We work closely with research groups in the anonymity space, the security space, in privacy research, etc. 

Tor is the focus of many researchers. We have rigorous documentation and open, transparent development processes. We also have a working product, Tor Browser, that easily reaches 1 to 2 million users, with testing channels where one can try new defenses first and refine them as needed, as we are doing with the Selfrando project. 

When will Selfrando be available for ordinary Tor users (in the stable version)?

The first thing to note here is that Selfrando is currently only available for a fraction of our users; those who have a 64-bit Linux systems. The Selfrando folks are working on a version for Windows which is not yet ready. 

I think that Tor browser version 6.5 might be a bit too early for a stable release. However, if user testing shows this is okay, Selfrando will make it in. A more conservative approach is pointing to Tor browser version 7.0.

That’s a pretty long time from now (next Spring!) How can people help Tor speed it up?

We need more users testing things--more experienced people trying out our nightly/alpha builds. 

Selfrando's development is good so far and the browser integration work has not been so tricky; the main problem is being confident enough that it does not break some random user setups while everything is fine and working on our testing machines.

Specifically, we need more experienced people running Linux 64-bit operating systems to download and try our hardened nightly builds. They can download the latest hardened nightly build and look for the latest "nightly-hardened" build in general at https://people.torproject.org/~linus/builds/. Obviously, these are test versions of the Tor Browser--we're trying to look for bugs.

Will there will be future collaborations with these researchers?

To port Selfrando to Windows and OSX and make it available to our users, yes!

How do you feel about the fact that the research community is teaming up with Tor to strengthen Tor browser against attacks?

I think this is great as it gives us another valuable ally to make our users safer. And in the longer run, all other users with "normal" browsers could benefit from that, too.

______________________________________________________________

The researchers behind Selfrando will present their project in July at the Privacy Enhancing Technologies Symposium in Darmstadt, Germany.

An advance copy of their research paper is available here.

Selfrando is available for use in other open-source projects on Github.

Snowden's Son in Law

June 23, 2016

Permalink

Very nice, I hope that this will help Tor be more secure, I give my best wishes to the creators, thanks.

-Anonymous

Snowden's Son in Law

June 23, 2016

Permalink

Hi,
will stock Firefox also use Selfrando? And what about Firefox packaged by distros like in e.g. Debian?
Thanks

Snowden's Son in Law

June 23, 2016

Permalink

This is great news!

Over the next 5-10 years for Tor to have any hope of frustrating the Police states everywhere consistently, it would appear several things are needed:

1) TBB patches are accepted upstream by Mozilla
2) The network loses dependence on anonymous guard/relay/exit nodes that are regularly poisoned and used in numerous forms of de-anonymization attacks by malicious actors
3) The network is scaled up in the order of several multiples
4) Quantum-resistant ciphers are used
5) A solution is found to the problem of global adversaries who control internet exchange points and autonomous systems. Perhaps a company might offer a million dollars for any group of researchers who can solve this problem outlined below in a practical fashion:

http://www.ohmygodel.com/publications/usersrouted-ccs13.pdf

"The results show that Tor faces even greater risks from traffic correlation than previous studies suggested. An adversary that provides no more bandwidth than some volunteers do today can deanonymize any given user within three months of regular Tor use with over 50% probability and within six months with over 80% probability.

Some of our results against an adversary controlling ASs or IXPs are similarly alarming. Some users experience over 95% chance of compromise within three months against a single AS or IXP."

6) Users are educated in using Tor in hardened virtualized systems only. They should understand that they will be the focus of frequent attacks in the wild and should assume they will be hacked at the browser/network level in due course. Solutions like Qubes, Whonix, and Subgraph O/S pose much promise in this space i.e. isolated, hardened, instances of Tor running in (mostly) read-only application VMs.

Keep up the great work!

Snowden's Son in Law

June 24, 2016

Permalink

Many, many thanks for this!
I consider myself "more experienced", yet looking at the hardened build directory leaves me confused. What do those archives contain? What do I need to download? Why is there no signature file for the *xz archive?
Some instructions (a README) would be much appreciated.

> We need more users testing things--more experienced people trying out our nightly/alpha builds.
>
> Selfrando's development is good so far and the browser integration work has not been so tricky; the main problem is being confident enough that it does not break some random user setups while everything is fine and working on our testing machines.

Just to clarify: "experienced people" means people experienced using stable Tor Browser to surf, not neccessarily experienced debuggers, right?

If so, I can try to help, but could use some instructions on reporting any bugs. Anonymously of course (so listserves are out).

"Experienced people" does merely mean users that are willing to try non-stable Tor Browser versions and, ideally, reporting bugs. And, no, no debugger experience is needed. :)

About reporting bugs: You can use our bug tracker (https://trac.torproject.org) with an anonymous account. See the "Unofficial Documentation" section for a how-to. Otherwise showing up on IRC in #tor-dev on irc.oftc.net should work as well or sending email to Tor Browser folks.

In

https://people.torproject.org/~linus/builds/tbb-nightly-hardened-2016-0…

I see

o tor-browser-linux64-tbb-nightly-hardened_ALL.tar.xz
o sha256sums-unsigned-build.txt
o sha256sums-unsigned-build.txt.asc

So I think the idea is that users with a 64bit Linux system should

o download all three of those
o obtain the correct signing GPG key
o verify the signature of the file holding the SHA256 hashes
o verify that tarball (the tar.xz archive) has the stated SHA256 hash
o unpack the tarball
o surf until you find some bugs
o report all bugs

If I misunderstood, then I am sure I am not the only one.

A FAQ for how to help with testing would be good, too....

Stuff like bug reporting procedure, which mailing lists and irc channels are relevant, etc. I consider myself a more experienced *user* but don't really know where to begin with testing. Do I just replace my normal Tor browsing activity with browsing using the nightly (as long as I'm not in a high risk situation)?

Ideally, just using the nightly instead is a good idea, yes. Unfortunately, we don't have a nightly update channel yet which makes keeping up-to-date a bit painful. We are working on it in https://bugs.torproject.org/18867.

Regarding bug reporting: I am happy about bug reports whichever medium you are preferring to use. We have our bug tracker (https://trac.torproject.org), we are usually hanging out in #tor-dev on irc.oftc.net if there are questions etc. There is a separate mailling list for Tor Browser development as well: tbb-dev and of course there are the individual mailing addresses for Tor people.

> We have our bug tracker (https://trac.torproject.org)

Can you post anonymously via Tails? Are unstructured bug reports ("I experienced this unexpected behavior and have no idea what caused it or whether it might be serious") useful, because this seems to be the only kind I can come up with. (Example: "seeing junk in gedit/file manager sidebars while using Tails, becomes readable when mouseover"; didn't realize at time of report that fact I was using 32-bit Tails on a 64-bit machine was probably relevant, that the likely cause was some slowdown in the crypto while accessing an encrypted USB stick.)

The structured forms are more for people who have read some of the code, I think.

> we are usually hanging out in #tor-dev on irc.oftc.net if there are questions etc.

Can Tails users still use irc.oftc anonymously via the Pidgin in Tails?

I am reluctant to expose myself for a one-off bug report of questionable utility (because I usually don't understand what I saw, sometimes not even sure I saw something real).

BTW, I think you may have been one of the people in Debian who understood years ago that Debian users were put at risk from state-sponsored hacking by unencrypted bug reports and popularity contest reporthttps://blog.torproject.org/blog/tors-innovative-metrics-program-receiv…; the Snowden leaks verified in detail that the fears expressed by some Debian users were not misplaced.

Thks again for replying! And for Selfrando!

You could use tor to create and access an account on the trac site used by devs to report bugs. @GK . A nice bug reporting guideline could help immensely. Informing new users of how to structure their reports and helping them think like testers. This guide should be pinned somewhere very noticeable in a relevant area.

In case anyone reads old comments like me right now, a caveat about Whisperback:

Most uniquely identifying information like network interface MACs are removed (i.e., "[MAC REMOVED]"), but the SSID of the wireless network you connected to still remains. Oops.

See for yourself. Open Whisperback, and copy and paste the 'debugging info' part (focus on it and use Select All or CTRL+A because there's too much text to select the whole lot) into Gedit and search for 'ssid'. Yet not only does the SSID remain, but for some reason one can't edit the debugging info anymore to remove it. Don't use Whisperback from home then!

I just checked this in TAILS 2.5 today.

Would be really nice and seamless if bug reporting were built into the test builds (in modular fashion). Maybe a second tool could run simultaneously to collect data about the browser. Like a supervisor. Omitting sensitive data while retaining things like what kind of elements loaded in the browser, what functions were called, etc. Users could opt out of using this observer tool any time they please. Could make testing more efficient.

Snowden's Son in Law

June 24, 2016

Permalink

And, after trying to verify sha256sums-unsigned-build.txt.asc: Why is the key 4D0DB324 not present on standard keyservers? Downloading that from the same server as the software itself does not add much value, does it?

Except that if you check the signatures of 0xD1982B344D0DB324, you'll see that Linus Nordberg did sign it with his own key 0x1E8BF34923291265, which is available on pool.sks-keyservers.net. Linus' key is itself heavily signed.

The key is 'only' 2,048 bit. Maybe a new key in future that's 4,096 bit and with several signatures from other Tor Project people is more satisfying, but there's enough already, yes? Perhaps the bigger threat is that these 'bleeding edge' builds almost certainly have undiscovered bugs, even if the signatures are watertight.

Be careful what you browse when testing: innocuous stuff first, so that if you are compromised, it's not embarrassing! Reserve sensitive stuff for well-tested releases.

> Be careful what you browse when testing: innocuous stuff first, so that if you are compromised, it's not embarrassing! Reserve sensitive stuff for well-tested releases.

Will do.

Actually, a list of globally popular but fairly innocuous and not horribly unsafe websites would be helpful. If it comes from TP not CIA, of course....

Snowden's Son in Law

June 24, 2016

Permalink

Some system info:
$ uname -a
3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS"

First attempt:
Starting with tor-browser/Browser/start-tor-browser --verbose
chrashes, where these are the last log messages:
Jun 24 09:14:27.711 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Jun 24 09:14:27.000 [notice] Parsing GEOIP IPv4 file /home/torbrowser/tor-browser/Browser/TorBrowser/Data/Tor/geoip.
Jun 24 09:14:28.000 [notice] Parsing GEOIP IPv6 file /home/torbrowser/tor-browser/Browser/TorBrowser/Data/Tor/geoip6.
Jun 24 09:14:29.000 [notice] Bootstrapped 0%: Starting
Jun 24 09:14:29.000 [notice] Delaying directory fetches: DisableNetwork is set.
[3809] ###!!! ABORT: X_ShmPutImage: BadShmSeg (invalid shared segment parameter); 3 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
[3809] ###!!! ABORT: X_ShmPutImage: BadShmSeg (invalid shared segment parameter); 3 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
ASAN:SIGSEGV
=================================================================
==3809==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000414dd6 bp 0x7f28cde84a10 sp 0x7f28cde84a00 T37)
SRAT init
ASAN:SIGSEGV
==3809==AddressSanitizer: while reporting a bug found another one. Ignoring.
Jun 24 09:14:42.000 [notice] Monitored process 3809 is dead.
Jun 24 09:14:42.000 [notice] Owning controller process has vanished -- exiting now.
Jun 24 09:14:42.000 [notice] Catching signal TERM, exiting cleanly.

Second attempt:
Without --verbose a language chooser appears. It remains empty for a long
time. Display of "Next" and "close" buttons takes longer still.
The browser starts. The first thing I see is "WARNING: this browser is out of
date."
A check for updates via the onion results in: Update XML file not found (404)

Third attempt.
Again with --verbose. Starts properly, but out of date WARNING remains.
Seems to work. I’m on "High" security level now.

Yes, that was with the first start of a clean install.
No, it's not reproducible. Today I got similar crashes twice again (from the previous installation directory, no new install):

Jun 28 08:53:29.000 [notice] New control connection opened from 127.0.0.1.
Jun 28 08:53:29.000 [notice] New control connection opened from 127.0.0.1.
[31474] ###!!! ABORT: X_ShmPutImage: BadShmSeg (invalid shared segment parameter); 3 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
[31474] ###!!! ABORT: X_ShmPutImage: BadShmSeg (invalid shared segment parameter); 3 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
ASAN:SIGSEGV
=================================================================
==31474==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000040e800 bp 0x7f1d1d826240 sp 0x7f1d1d826230 T27)
SRAT init
ASAN:SIGSEGV
==31474==AddressSanitizer: while reporting a bug found another one. Ignoring.

On the third attempt, Tor Browser nightly started.

Also the non-hardened version tor-browser-linux64-tbb-nightly_ALL.tar.xz (2016-06-30) crashes from time to time (only directly upon startup):

Jul 01 15:59:06.000 [notice] New control connection opened from 127.0.0.1.
[6012] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
[6012] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
Jul 01 15:59:07.000 [notice] Owning controller connection has closed -- exiting now.
Jul 01 15:59:07.000 [notice] Catching signal TERM, exiting cleanly.
/home/torbrowser/tor-browser/Browser/start-tor-browser: Zeile 372: 6012 Speicherzugriffsfehler (Speicherabzug geschrieben) TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor Browser" -profile TorBrowser/Data/Browser/profile.default "${@}" < /dev/null

This is for the July 9 version.

Immediately after the run command I see (not sure whether the warning is relevant):
Starting program: /home/torbrowser/tor-browser/Browser/firefox -profile Browser/TorBrowser/Data/Browser/profile.default
warning: the debug information found in "/lib64/ld-2.19.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

Note that for the first start I had to press "c" several times in the debugger.
Eventually I got this:
Jul 11 14:55:29.000 [notice] New control connection opened from 127.0.0.1.
Jul 11 14:55:29.000 [notice] New control connection opened from 127.0.0.1.
[New Thread 0x7fffc3aff700 (LWP 1315)]
[New Thread 0x7fffc22ff700 (LWP 1316)]
[1254] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
[1254] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc74ff700 (LWP 1308)]
mozalloc_abort (
msg=msg@entry=0x7fffc74fd6cc "[1254] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157")
at /home/debian/build/tor-browser/memory/mozalloc/mozalloc_abort.cpp:33
33 /home/debian/build/tor-browser/memory/mozalloc/mozalloc_abort.cpp: Datei oder Verzeichnis nicht gefunden.
(gdb) Jul 11 14:55:30.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Jul 11 14:55:30.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Jul 11 14:55:30.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jul 11 14:55:30.000 [notice] Bootstrapped 100%: Done

(It wasn’t clearly visible that a gdb command prompt is available. Pressing
enter showed that it was, though.)
bt output:
#0 mozalloc_abort (
msg=msg@entry=0x7fffc74fd6cc "[1254] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157")
at /home/debian/build/tor-browser/memory/mozalloc/mozalloc_abort.cpp:33
#1 0x00007ffff2199393 in Abort (
aMsg=0x7fffc74fd6cc "[1254] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157") at /home/debian/build/tor-browser/xpcom/base/nsDebugImpl.cpp:452
#2 NS_DebugBreak (aSeverity=,
aStr=0x7fffc2ca6e58 "X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago", aExpr=0x0,
aFile=0x7ffff45066de "/home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp", aLine=157)
at /home/debian/build/tor-browser/xpcom/base/nsDebugImpl.cpp:439
#3 0x00007ffff37feeb3 in X11Error (display=0x7ffff69e9000, event=)
at /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp:157
#4 0x00007fffee6f354b in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007fffee6f05e7 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007fffee6f0695 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007fffee6f1578 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8 0x00007fffee6ed0cd in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9 0x00007ffff332601b in nsShmImage::Create (aSize=..., aDisplay=0x7ffff69e9000, aVisual=, aDepth=)
at /home/debian/build/tor-browser/widget/nsShmImage.cpp:78
#10 0x00007ffff3326154 in nsShmImage::EnsureShmImage (aSize=..., aDisplay=, aVisual=,
aDepth=, aImage=...) at /home/debian/build/tor-browser/widget/nsShmImage.cpp:193
#11 0x00007ffff33376a8 in nsWindow::GetDrawTarget (this=0x7fffe931a750, aRegion=...)
at /home/debian/build/tor-browser/widget/gtk/nsWindow.cpp:6478
#12 0x00007ffff332db9b in nsWindow::StartRemoteDrawingInRegion (this=, aInvalidRegion=...)
at /home/debian/build/tor-browser/widget/gtk/nsWindow.cpp:6497
#13 0x00007ffff27a98a6 in mozilla::layers::BasicCompositor::BeginFrame (this=0x7fffdc280110, aInvalidRegion=..., aClipRectIn=0x0,
aRenderBounds=..., aClipRectOut=0x7fffc74fe860, aRenderBoundsOut=0x7fffc74fe840)
at /home/debian/build/tor-browser/gfx/layers/basic/BasicCompositor.cpp:552
#14 0x00007ffff27cadc1 in mozilla::layers::LayerManagerComposite::Render (this=this@entry=0x7fffc283af00, aInvalidRegion=...)
at /home/debian/build/tor-browser/gfx/layers/composite/LayerManagerComposite.cpp:795
#15 0x00007ffff27cb3b1 in mozilla::layers::LayerManagerComposite::UpdateAndRender (this=this@entry=0x7fffc283af00)
at /home/debian/build/tor-browser/gfx/layers/composite/LayerManagerComposite.cpp:389
#16 0x00007ffff27cb480 in mozilla::layers::LayerManagerComposite::EndTransaction (this=0x7fffc283af00, aTimeStamp=...,
aFlags=) at /home/debian/build/tor-browser/gfx/layers/composite/LayerManagerComposite.cpp:316
#17 0x00007ffff27e1503 in mozilla::layers::CompositorParent::CompositeToTarget (this=0x7fffc2aa8400, aTarget=aTarget@entry=0x0,
aRect=aRect@entry=0x0) at /home/debian/build/tor-browser/gfx/layers/ipc/CompositorParent.cpp:1160
#18 0x00007ffff27e160f in mozilla::layers::CompositorVsyncScheduler::ComposeToTarget (this=this@entry=0x7fffc3b22700,
aTarget=aTarget@entry=0x0, aRect=aRect@entry=0x0) at /home/debian/build/tor-browser/gfx/layers/ipc/CompositorParent.cpp:559
#19 0x00007ffff27e1674 in mozilla::layers::CompositorVsyncScheduler::Composite (this=0x7fffc3b22700, aVsyncTimestamp=...)
at /home/debian/build/tor-browser/gfx/layers/ipc/CompositorParent.cpp:440
#20 0x00007ffff235d205 in MessageLoop::RunTask (this=0x7fffc74fecf8, task=0x7fffc2ad89a0)
at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:364
#21 0x00007ffff2361101 in MessageLoop::DeferOrRunPendingTask (this=, pending_task=...)
at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:372
#22 0x00007ffff236120f in MessageLoop::DoWork (this=0x7fffc74fecf8)
at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:459
#23 0x00007ffff235d3e4 in base::MessagePumpDefault::Run (this=0x7fffd30de070, delegate=0x7fffc74fecf8)
at /home/debian/build/tor-browser/ipc/chromium/src/base/message_pump_default.cc:34
#24 0x00007ffff235d264 in RunHandler (this=) at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:227
#25 MessageLoop::Run (this=this@entry=0x7fffc74fecf8) at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:201
#26 0x00007ffff2367546 in base::Thread::ThreadMain (this=0x7fffd30f5a60)
---Type to continue, or q to quit---
at /home/debian/build/tor-browser/ipc/chromium/src/base/thread.cc:172
#27 0x00007ffff2363237 in ThreadFunc (closure=)
at /home/debian/build/tor-browser/ipc/chromium/src/base/platform_thread_posix.cc:36
#28 0x00007ffff7bc4184 in start_thread (arg=0x7fffc74ff700) at pthread_create.c:312
#29 0x00007ffff6c3a37d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Snowden's Son in Law

June 24, 2016

Permalink

A million thanks to the Selfrando researchers and the Tor Browser team!

And special thanks to those Debian developers who are working for better security in Debian too.

Here are two news articles on Selfrando:

http://www.theregister.co.uk/2016/06/23/tot_project_selfrando/
Tor onion hardening will be tear-inducing for feds
Onion rings get more scrambled
Darren Pauli
23 Jun 2016

> ...
> It is hoped the technique described in the paper Selfrando: Securing the Tor Browser against De-anonymisation Exploits [PDF] will help to frustrate deanonymisation efforts by government agencies. Selfrando, currently under testing in hardened Tor versions, is described as an "enhanced and practical load-time randomisation technique" that defends against exploits, namely that allegedly used by the FBI.
>
> The [authors of the Selfrando paper] cite the 2013 attacks in which the FBI compromised Tor hidden services servers to deliver an exploit to de-anonymise users. The exploit abused an use-after-free vulnerability in Firefox to gain arbitrary code execution. "The main payload of the exploit collected the MAC address and the host name from the victim machine and sent the data to an attacker-controlled web server, bypassing Tor," they write. "That message also included a unique ID provided by the booby-trapped page in order to correlate a specific user to a specific visit."

https://motherboard.vice.com/read/tor-is-teaming-up-with-researchers-to…
Tor Is Teaming Up With Researchers To Protect Users From FBI Hacking
Joshua Kopstein
19 Jun 2016

> ...
> The new method is meant to counteract what's known as “code reuse” exploits, where rather than attempting the much harder task of injecting new malicious code, an attacker will exploit a memory leak to reuse code libraries that already exist in the browser—essentially, building malware by rearranging things inside the application's memory. To do that, an attacker generally needs to have an idea of where certain functions are located within the application's memory space. But the current security mechanisms in browsers only randomize the locations of code libraries, not the individual functions. Which is where the Selfrando technique comes in, creating a random address space for internal code that's much harder to exploit.

Snowden's Son in Law

June 24, 2016

Permalink

> The first thing to note here is that Selfrando is currently only available for a fraction of our users; those who have a 64-bit Linux systems.

Many people who use Linux use mostly 32-bit because that is what is available. Which may be why Tails does not offer 64 bit versions yet.

That said, any time =line on when the hardened browser may become standard in Tails?

Tails is still 32-bit to maintain compatibility with very old computers. Anyone who has installed Linux on a desktop this decade is most likely running with all 64 of the bits.

As a long time Tails user I actually support the design decision to offer 32 bit only for now because many users including me only have access to limited hardware. Many of the most endangered users live where only certain hardware is available.

Why not offer both 32 and 64 bit as does Tor for stable TBB? Presumably because that increases the workload and the chance for a bad mistake which can be exploited by our enemies.

Also, Tails devs obviously had to work very hard to rebase Tails on current Debian stable. This was important for many reasons and led to cleaning up much potentially dangerous cruft. Hopefully the next Debian rollover will not be such a challenge for Tails.

All that said, I very much want to see Selfrando and other hardenings incorporated in Tails ASAP. All like minded people: please consider contributing to Tails via FOTP foundation or another foundation which can route donations to Tails team.

Normal Tor Browser has many additional security features over Vanilla Firefox. The article says Selfrando will for the moment only be in Linux Testing version, it doesn't say it's restricted to the Hardened release. The difference between Hardened testing and normal testing is that Hardened uses Address Sanitizer (ASan.) ASan requires several times more memory and gives a significantly noticable slowdown. 32bit simply doesn't have the memory to use ASan in large applications, like a modern web browser.

Snowden's Son in Law

June 24, 2016

Permalink

One US judge has a rather unique perspective on the security flaws which Selfrando hopes to address:

http://arstechnica.com/tech-policy/2016/06/fbis-use-of-tor-exploit-is-l…
FBI’s use of Tor exploit is like peering through “broken blinds”
Judge: Making a computer reveal its IP address does not constitute a search.
Cyrus Farivar
24 Jun 2016

> Law enforcement does not need a warrant to hack someone’s computer, according to a just-unsealed court order written by a federal judge in Virginia.
> ...
> As Ars has reported before, to breach the security normally afforded by Tor, the FBI deployed a "network investigative technique" (NIT). In a related case prosecuted out of New York, an FBI search warrant affidavit described both the pornography available to Playpen’s 150,000 members and the NIT's capabilities. As a way to ensnare users, the FBI took control of Playpen and ran it for 13 days in 2015 before shutting it down. During that period, with many users’ Tor-enabled digital shields down—revealing their true IP addresses—the government was able to identify and arrest the 135 child porn suspects.
> ...
> US District Judge Henry Coke Morgan, Jr. further explained in the order on Thursday that warrantless government-sanctioned hacking "resembles" law enforcement looking through broken blinds. In this case, however, a warrant was sought and obtained. Judge Morgan found that even if the warrant did not exist—or was found to be invalid—the search would have been valid.

So should Tom wish to peer at a young girl undressing in her bedroom, that would be fine with Judge Morgan so long as Tom is peering through "broken" blinds? Broken so obscurely that the victim does not notice anything amiss?

No, judge, you are wrong about that. Wrong as wrong could be.

You want an analogy, judge? Let me suggest one: unwarranted state-sponsored rape. You now, like this incident (one of many):

> The CBP Agent became more aggressive in his questions and accusations. That CBP Agent directed Ashley to follow him to a “detention” room, ostensibly for additional questioning. Over the course of the next few hours, Ashley:
>
> a. was handcuffed to a chair;
>
> b. had a number of CBP K9’s sniff her person (a violation of CBP policy, which prohibits the use of K9’s on a person); and,
>
> c. was taken into a separate room, patted down, and asked to squat so female investigators could visually inspect her.
>
> At no point was Cervantes advised of her Miranda rights, because forget it, Jake, it's Bordertown. The CBP's inability to locate the drugs the agent fervently believed Cervantes was smuggling into the country didn't result in the conclusion of the search. Instead, efforts escalated under the theory that Cervantes was just particularly skilled in the art of concealing drugs.
>
> First, the CBP agent deployed his own questionable medical skills to fill out a "Treatment Authorization Request." In this Immigration Health Services' form, the agent "diagnosed" Cervantes as a "potential internal carrier of foreign substances" and ordered up an X-ray. Cervantes was placed in a CBP van and taken to Holy Cross Hospital, where an all-too-willing accomplice was found in the form of Dr. Patrick F. Martinez. Once there, more questionable paperwork was completed by those involved.
>
> The Holy Cross records from Ashley’s time at the facility include a number of factual inaccuracies, including inaccurately setting out that Ashley was accompanied by her mother and arrived in a private vehicle. In reality, Ashley was transported in a CBP vehicle. Her handcuffs were not removed until she changed into a hospital gown for the alleged purpose of undergoing an X-Ray.
>
> Cervantes never underwent an X-ray. Instead, she underwent a series of non-consensual penetrations -- something most people refer to as "rape."
>
> Dr. Martinez, a male physician, entered Ashley’s room and, after asking a few cursory questions, brutally invaded her body on a warrantless and unjustified search for contraband.
>
> Dr. Martinez forcefully and digitally probed Ashley’s vagina and anus.
>
> Ashley had never before been to a gynecologist and, for the remainder of her life, will always remember that her first pelvic and rectal exams were under the most inhumane circumstances imaginable to a U.S. citizen at a hospital on U.S. soil.
>
> The searches conducted by the CBP Agents, Holy Cross and Dr. Martinez injured Ashley physically, mentally and emotionally. Her labia, vaginal opening, and anus were left raw and sore and she felt violated, demeaned and powerless as a result of the searches.
>
> Seven hours. No drugs. Multiple penetrations. No warrants. No consent. And all of this will likely be OK -- or at least not enough to leap the "qualified immunity" hurdle.
>
> The courts have frequently held that the Fourth Amendment is nothing to get too concerned about near our nation's borders, what with drugs and terrorism on the loose. If the courts find it acceptable for the CBP to seize laptops and other devices and search them without a warrant, it stands to reason they'll probably find seizing and searching the lower half of a human being without probable cause to be just one of those things that happen in service of the public's "best interest."

https://motherboard.vice.com/read/court-rules-the-fbi-does-not-need-a-w…
Court Rules the FBI Does Not Need a Warrant to Hack a Computer
Joseph Cox
23 Jun 2016

> “The Court finds that no Fourth Amendment violation occurred here because the Government did not need a warrant to capture Defendant's IP address,” Henry Coke Morgan, Jr., a senior United States District Judge, wrote in an opinion and order on Tuesday. He adds that the government did not require a warrant to extract other information from the suspect’s computer either.
> ...
> According to activists, the ruling could have serious implications for how law enforcement is able to conduct remote searches... “The implications for the decision, if upheld, are staggering: law enforcement would be free to remotely search and seize information from your computer, without a warrant, without probable cause, or without any suspicion at all,” Mark Rumold, senior staff attorney at the Electronic Frontier Foundation wrote in a blog post on Thursday.

"We're the government, and we are here to rape you. Bend over. We are doing this for your own good."

https://motherboard.vice.com/read/the-fbi-is-classifying-its-tor-browse…
The FBI Is Classifying Its Tor Browser Exploit Because 'National Security'
Joseph Cox
24 Jun 2016

> Defense teams across the US have been trying to get access to a piece of malware the FBI used to hack visitors of a child pornography site. None have been successful at obtaining all of the malware's code, and the government appears to have no intention of handing it over. Now, the FBI is classifying the Tor Browser exploit for reasons of national security, despite the exploit already being used in normal criminal investigations well over a year ago. Experts say it indicates a lack of organization or technical capabilities within the FBI.

"So, you say you were raped by a federal agent? Then here's another 20 points added to your prototerrorism score. Now we need to re-examine you. Bend over."

Snowden's Son in Law

June 24, 2016

Permalink

The hardened version works great! However I should also mention it eats up a lot of RAM and can easily go above 4-5 GB of RAM if you open lots of tabs. Of course people using 64bit linux often have lots of memory but still it requires some equipment.

I don't know if it works inside whonix, which I believe is 32bit.

Anyway, it works great, never crashes and looks rock stable! Thank you for your hard work!

Whonix is 64bit for the Qubes version; otherwise you're right, whonix only distributes 32bit builds. Of course, you can build it yourself...
Then again, anyone with a computer that can run Hardened Tor Browser (with the performance hit from ASan) inside a virtualizer with any reasonable amount of speed has a good chance of being able to run Qubes, and Qubes is (considered) more secure than the other VMs.
Of course, Qubes is an OS in and of itself, so it really isn't a solution for someone who doesn't want to radically change their system and isn't already running Qubes.

Snowden's Son in Law

June 25, 2016

Permalink

Currently the most readily accessible ( to non tech testers ) "system"
that is around from credible sources is the 32bit Debian8 whonix system.

Can you please wrap this in a dedicated 64bit VM appliance that will
allow folks to exercise, and compare it with the stock version?

Then it may be ued with a standard gateway VM - or a variant that
can also test the effectiveness of the latest development tor code:
packaged to permit the user to send back to you - at their consent -
"tet runs" from their own personal ISP - or selected Pubblic WiFi.

I do such things already, mostly to attempt to reverse engineer the
technicques of de-anonymity or other active interference that is
likely to be experiended by "lone wolf" targets that are otherwise
entirely law-abiding, but determined to preserve pricacy rights in
any free society within the global nework of taxpayer funded
mass surveillance.

More numbers / users and consistent testing environments make
for better statistics and reference data

Sounds great but reduces diversity. I think it's important that we allow users to run this hardened build on as many OS environments as possible. It would be great if installing was as easy as one two click go! The focus should be to make it easy as pie to run on any system. Always. Not just for testing.

Snowden's Son in Law

June 26, 2016

Permalink

I am a brand new Tor user. While using the Tor Browser to search using Google, Google is asking me to type in a series of characters to verify I am not a robot... I didn't do it as I would think that gives them info. Is it OK to do what they are asking??

That is basically just a form of CAPTCHA, but yes, if you have JavaScript enabled for Google then they may be able to glean some information from your response.

The real answer here, though, is that you shouldn't be using Google if you care about anonymity. They have a long track record about being very aggressive in tracking people and numerous "accidental" privacy breaches.

Instead, I (and others) recommend using a privacy-respecting search engine such as DuckDuckGo, StartPage or Disconnect— one of which should have been Tor Browser's default search engine to begin with.

I would like to add that Startpage displays the exact same search results as google. Aside from a few variables, you should get the same experience with the exception of how it all looks. Some people just can't stand to go without all of googles' pretty colors and presentation ;P

> Nothing to see here.

We should always do more of whatever we are doing that causes our enemies to express concern about "losing access" in internal memos, while treating with skepticism loudly trumpeted "panic" about "going dark" (e.g. in public testimony to US Congress).

And I think it is an invaluable service to Tor users to provide some details on what TP is doing to make TBB better.

>And I think it is an invaluable service to Tor users to provide some details on what TP is doing to make TBB better.
Literally read the changelog. Holy fuck, you don't an entire blog post to tell your users what you did. What's next? Is TP going to start following Apple's footsteps and begin hosting entire conferences to tell you what they could've told you in a changelog?

> Literally read the changelog. Holy fuck, you don't an entire blog post to tell your users what you did. What's next? Is TP going to start following Apple's footsteps and begin hosting entire conferences to tell you what they could've told you in a changelog?

I strongly support the Project's attempts to broaden the user base, to make tor easier for many more potentially endangered users to install and use tor with the greatest possible degree of safety. And few ordinary users are likely to get very much out of a change log, since these typically offer little to no background explanations for the layperson. That said, I'd like to see even more effort to explain even more technical matters in terms which can be understood by laypersons, preferably including those whose first language is not English. Tall order, I know.

Dude, this significantly increases the address space and randomizes the location of each function on startup. What we see here is great leap in browser security. Couple this with disabling javascript and an attacker is going to be really pissed.