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

Sun Sep 11 02:00:07 UTC 2016

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

Comment (by teor):

 Replying to [comment:6 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.

 I'm not sure if we recommend running hidden services and hidden service
 clients from the same Tor instance. I think there are some anonymity
 implications. But not so severe that we prevent it entirely.

 ...

 > > 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.

 OK, so we are clearly not sandboxing that directory correctly, or SETCONF
 is doing something unnecessary.

 > > 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.)

 That would be helpful, but others will step in at some point if you can't.

 > 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.

 I would love to see debug symbols here.
 Can you install tor-dbg?

 Are the directory permissions for /var/lib/tor/hidden_service/ and
 /var/lib/tor/ identical on Stretch and Tails?
 Is the owner of /var/lib/tor/hidden_service/ and /var/lib/tor/ the same
 user tor runs as on both Stretch and Tails?
 (Tor might act differently depending on these permissions.)

 Is the sandboxing config in the kernel identical?
 (There might be a deny vs terminate setting.)

 An error on SETCONF is bad, but a crash is really nasty.

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