Support shared onion pool for DNS resolution in separate process

So it turns out that in irssi is doing DNS resolution in an other process and passing the result back to the first process which will make the connection.

This means that the two process have two distinct onion pools so the process doing the DNS resolution will store the onion address with the reserved cookie but the other process, when connecting using that cookie, will be unable to find the onion address in its pool.

One solution I have in mind is to create that onion pool in a shared memory (SHM) and hijack the clone/fork symbol so when we detect a new process we can set the onion pool reference in it thus sharing the pool across processes that have a common parent.

I have a PoC that works but maybe there could be an IPC approach instead.

added component::core tor/torsocks in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac type::enhancement in Legacy / Trac labels

Accept a bunch of tickets for torsocks.

Trac:
Status: new to accepted

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

Releasing some old tickets.

Trac:
Owner: dgoulet to N/A
Status: accepted to assigned

Change tickets that are assigned to nobody to "new".

Trac:
Status: assigned to new

moved from legacy/trac#11727 (moved)

added Feature label and removed 1 deleted label

removed 1 deleted label

Hijacking clone/fork + shared memory sounds like a reasonable approach to me. Is there a reason not to move forward with that approach? And would it be worth trying to fix up and merge the proof of concept, or is it too bit-rotted at this point?

mentioned in issue tpo/community/team#30 (moved)

I just got hit by this bug while trying to run irssi with torsocks.

It took me a while to figure out what's happening there, especially as the error messages returned by torsocks are pretty misleading. In its default configuration, with OnionAddrRange set to a link-local network, torsocks reports the following error message in that case:

Connection to a local address are denied since it might be a TCP DNS query to a local DNS server. Rejecting it for safety reasons

This error message might lead users to enable AllowOutboundLocalhost, which doesn't solve this issue, but might weaken their safety.

I'd appreciate a fix for this issue as well.

I wonder whether tor already supports onion addresses through its DNS resolution APIs, e.g. via its own (global) address/fake-IP mapping. If so, would there be a reason not to use it? Or would that violate some isolation policy?

That could work, but only if it's turned on. It might be turned off in Tor. I guess you could detect that and fail closed somehow?

(Also, for security, it's much better to use IPv6 addresses for that: Using IPv4 addresses here makes enumeration possible.)

Experimentally, the answer appears to be that no, tor does not already support this. Of course it couldn't be that easy :)

After setting DNSPort 54:

$ dig @localhost -p 54 facebookcorewwwi.onion

; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> @localhost -p 54 facebookcorewwwi.onion
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10142
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;facebookcorewwwi.onion.		IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#54(127.0.0.1)
;; WHEN: Mon Mar 29 15:14:57 CDT 2021
;; MSG SIZE  rcvd: 40

Ah, I missed a config option

After also setting AutomapHostsOnResolve 1:

$ dig @localhost -p 54 facebookcorewwwi.onion

; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> @localhost -p 54 facebookcorewwwi.onion
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23543
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;facebookcorewwwi.onion.		IN	A

;; ANSWER SECTION:
facebookcorewwwi.onion.	60	IN	A	127.214.176.89

;; Query time: 0 msec
;; SERVER: 127.0.0.1#54(127.0.0.1)
;; WHEN: Mon Mar 29 15:20:02 CDT 2021
;; MSG SIZE  rcvd: 56

So looks like this could work, but requires some torrc configuration.

@nickm thanks - I'll check into the options for using ipv6...

I do like the idea at least as a short/medium-term workaround to figure out if this option is enabled in tor, and if so use that instead of torsocks's implementation.

We could check the output of /usr/bin/tor --dump-config full; or maybe more reliably just try looking up some test onion address.

I've hacked up a local workaround. Not mergeable in its current state, but to track progress (and document for anyone adventurous enough to reproduce locally):

Added an onion service to my irssi config. (I just searched for any irc onion service; I don't know anything about this one in particular)

In ~/.irssi/config:

servers = (
  {
    address = "ljxozsuo3rkfhdedxxy5hr7vanxix5rhx7agvplsht5libgqeov3qfid.onion";
    chatnet = "ircd";
    port = "6667";
    use_tls = "no";
  },

In torrc:

# Enable automapping in tor
AutomapHostsOnResolve 1

# Disable ipv6 automap; torsocks doesn't support it yet
SOCKSPort 9050 NoPreferIPv6Automap

And finally I had to hack up my local torsocks to not do its own onion mapping, so that it'd use tor's automap instead, and to allow connection to a "local" IP:

diff --git a/src/lib/connect.c b/src/lib/connect.c
index 854e994..2af5449 100644
--- a/src/lib/connect.c
+++ b/src/lib/connect.c
@@ -178,7 +178,7 @@ LIBC_CONNECT_RET_TYPE tsocks_connect(LIBC_CONNECT_SIG)
                 * .onion cookie address that is by default in the loopback network
                 * thus this check is done after the onion entry lookup.
                 */
-               if (utils_sockaddr_is_localhost(addr)) {
+               if (0 && utils_sockaddr_is_localhost(addr)) {
                        /*
                         * Certain setups need to be able to reach localhost, despite
                         * running torsocks. If they enabled the config option, allow such
diff --git a/src/lib/torsocks.c b/src/lib/torsocks.c
index 16f2da0..324fc10 100644
--- a/src/lib/torsocks.c
+++ b/src/lib/torsocks.c
@@ -549,7 +549,7 @@ int tsocks_tor_resolve(int af, const char *hostname, void *ip_addr)
         * reserved IP address that acts as a cookie that we will use to find the
         * onion hostname at the connect() stage.
         */
-       if (utils_strcasecmpend(hostname, ".onion") == 0) {
+       if (0 && utils_strcasecmpend(hostname, ".onion") == 0) {
                struct onion_entry *entry;
 
                entry = get_onion_entry(hostname, &tsocks_onion_pool);

As discussed earlier, I think we can either add an option in torsocks to use tor's automap, or just probe to see if it works.

The local address handling is trickier. Normally torsocks makes an exception for addresses it knows are an onion cookie. We could add logic to the resolver to remember the onion cookies we get back from tor, but we'd have the same problem with irssi: irssi's process that makes the connection wouldn't know that the given address is an onion cookie.

tor has an option ClientRejectInternalAddresses that seems like it'd move this logic into tor. Relying on that adds a footgun for users who use this feature without setting ClientRejectInternalAddresses, though. Maybe torsocks should check/probe that setting as well and allow internal addresses if tor is already blocking them (thus allowing tor-provided onion cookies to work across processes)

assigned to @jnewsome

Some options:

Matt: torsocks.conf supports 'AllowOutboundLocalhost 0|1|2'

Nick: Tor always returns its local addresses from a given range specified in VirtualAddrNetworkIPv[46] , so you could in theory detect them like that. defaults are 127.192.0.0/10 and [FE80::]/10

@jnewsome are you still working on this?

@nickm Not actively. I might circle back to it the next time I have a chance to work on !shadow, but if someone else is interested in taking it in the meantime by all means go for it :)

ok, unassigning.

added Icebox label

unassigned @jnewsome