[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #20007 [Core Tor/Tor]: Sandbox causing crash when setting HidServAuth when there is a hidden service running
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs