[tor-bugs] #20007 [Core Tor/Tor]: Sandbox causing crash when setting HidServAuth when there is a hidden service running

Fri Sep 9 14:58:23 UTC 2016

#20007: Sandbox causing crash when setting HidServAuth when there is a hidden
service running
--------------------------------+------------------------------------
 Reporter:  segfault            |          Owner:
     Type:  defect              |         Status:  needs_information
 Priority:  Medium              |      Milestone:
Component:  Core Tor/Tor        |        Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal              |     Resolution:
 Keywords:  regression, tor-hs  |  Actual Points:
Parent ID:                      |         Points:
 Reviewer:                      |        Sponsor:
--------------------------------+------------------------------------

Comment (by segfault):

 > What are you really trying to do?
 > !HidServAuth is a client option, but you are running a hidden service.
 Did you mean to use !HiddenServiceAuthorizeClient instead?

 No, I did not confuse !HidServAuth with !HiddenServiceAuthorizeClient. I'm
 developing the Tails Server, which is an application run inside Tails to
 start hidden services (with client authentication). There is also a small
 client application, which primarily sets the client authentication cookie
 via !`SETCONF HidServAuth`, to be able to connect to a service started via
 Tails Server. Now it's possible that a user who runs a hidden service also
 wants to connect to another hidden service, which is when this issue would
 occur.

 > What is actually happening?
 > What is the full log? I'd like to see notice level.

 The two warn level messages are the only ones related to this issue. Here
 is the full notice level log:

 {{{
 # /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc
 --[wiki:RunAsDaemon] 0 --Log notice --[wiki:CookieAuthentication] 0
 --Sandbox 1 --[wiki:HiddenServiceDir] /var/lib/tor/hidden_service/
 --[wiki:HiddenServicePort] 80
 Sep 09 14:42:01.037 [notice] Tor 0.2.9.2-alpha (git-0b1c884a450cad98)
 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2h and Zlib
 1.2.8.
 Sep 09 14:42:01.037 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Sep 09 14:42:01.037 [notice] This version is not a stable Tor release.
 Expect more bugs than usual.
 Sep 09 14:42:01.037 [notice] Read configuration file "/usr/share/tor/tor-
 service-defaults-torrc".
 Sep 09 14:42:01.037 [notice] Read configuration file "/etc/tor/torrc".
 Sep 09 14:42:01.044 [notice] Opening Socks listener on 127.0.0.1:9050
 Sep 09 14:42:01.044 [notice] Opening Socks listener on 127.0.0.1:49050
 Sep 09 14:42:01.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
 Sep 09 14:42:01.000 [notice] Parsing GEOIP IPv6 file
 /usr/share/tor/geoip6.
 Sep 09 14:42:01.000 [notice] Bootstrapped 0%: Starting
 Sep 09 14:42:01.000 [notice] Bootstrapped 80%: Connecting to the Tor
 network
 Sep 09 14:42:02.000 [notice] Opening Control listener on
 /var/run/tor/control
 Sep 09 14:42:02.000 [notice] Bootstrapped 85%: Finishing handshake with
 first hop
 Sep 09 14:42:02.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
 Sep 09 14:42:03.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 Sep 09 14:42:03.000 [notice] Bootstrapped 100%: Done
 Sep 09 14:42:06.000 [notice] New control connection opened.
 Sep 09 14:42:06.000 [warn] Directory /var/lib/tor/hidden_service/ cannot
 be read: Permission denied
 Sep 09 14:42:06.000 [warn] Controller gave us config lines that didn't
 validate: Failed to configure rendezvous options. See logs for details.
 }}}

 > Does the hidden service work with the Sandbox on startup (without the
 SETCONF)? Is this simply a permissions problem on the directory?

 The hidden service works with the Sandbox without the SETCONF, so this is
 not only a permissions problem.

 > What is actually causing the issue?
 >
 > rend_parse_service_authorization() parses client HidServAuth entries, it
 doesn't read any service HiddenServiceDirectory files. So it might be that
 any SETCONF is your problem here, not specifically HidServAuth. What
 happens when you issue a SETCONF ClientOnly=1 instead of HidServAuth?
 (ClientOnly is ignored on clients, it has no effect).

 Indeed, it seems like every SETCONF fails like this (I tested it with
 SETCONF ClientOnly=1 and SETCONF Log debug). I'm sorry I missed this - I
 discovered this issue while investigating #20003, which is an issue
 regarding the sandbox and HidServAuth (but it does not occur in recent tor
 versions anymore). So I somehow assumed that this issue was also about
 HidServAuth.

 > rend_services_add_filenames_to_lists() implements the Sandbox for each
 HiddenServiceDirectory, using the following lines:
 >
 > rend_service_add_filenames_to_list(open_lst, s);smartlist_add(stat_lst,
 tor_strdup(s->directory));
 >
 > As far as I can see, this code is working correctly, and should make the
 hidden service directory available via the sandbox at startup. Maybe this
 directory isn't being added to the sandbox at startup? Maybe SETCONF isn't
 using the sandbox-approved way to access the directory?

 These seem like probable causes for this issue. Should I investigate this
 further? (I don't have too much time to work on this stuff these days, and
 have a lot of other issues to work on.)

 Note that the output from above is not from Tails, but from a vanilla
 Debian Stretch (I wanted to make sure that this is not a Tails specific
 issue), but I also tested it in Tails today with the same Tor version
 (0.2.9.2-alpha) and the output differs. In my Debian Stretch there are
 only the warning messages, but tor doesn't actually crash. In Tails, there
 are not warning messages, tor just crashes with the following traceback:

 {{{
 ============================================================ T= 1473422698
 (Sandbox) Caught a bad syscall attempt (syscall open)
 /usr/bin/tor(+0x15990c)[0xf769790c]
 /lib/i386-linux-gnu/libpthread.so.0(__open64+0x3d)[0xf71d8dbd]
 /lib/i386-linux-gnu/libpthread.so.0(__open64+0x3d)[0xf71d8dbd]
 /usr/bin/tor(check_private_dir+0x58)[0xf7690558]
 /usr/bin/tor(rend_config_services+0x402)[0xf75a39a2]
 /usr/bin/tor(+0xd84d3)[0xf76164d3]
 /usr/bin/tor(options_trial_assign+0x8d)[0xf761a01d]
 /usr/bin/tor(+0xfcf31)[0xf763af31]
 /usr/bin/tor(connection_control_process_inbuf+0x8a3)[0xf763ef03]
 /usr/bin/tor(+0xe1d4d)[0xf761fd4d]
 /usr/bin/tor(+0xeb11b)[0xf762911b]
 /usr/bin/tor(+0x32c09)[0xf7570c09]
 /usr/lib/i386-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x73d)[0xf745a36d]
 /usr/bin/tor(do_main_loop+0x2b7)[0xf7571d27]
 /usr/bin/tor(tor_main+0xdb5)[0xf75746f5]
 /usr/bin/tor(main+0x35)[0xf756d365]
 /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf706b723]
 /usr/bin/tor(+0x2f3c4)[0xf756d3c4]__
 }}}

 It seems like in my Debian Stretch the permission error is caught
 somewhere, but in Tails it is not.

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