Opened 4 years ago

Closed 6 weeks ago

Last modified 5 weeks ago

#15421 closed defect (fixed)

Relay crash when reloading and resolv.conf is empty

Reported by: TvdW Owned by: nickm
Priority: High Milestone: Tor: 0.4.0.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7.1-alpha
Severity: Normal Keywords: tor-relay, resolv.conf, dns, dos-maybe, 034-triage-20180328, 034-included-20180405, security, crash, 035-removed-20180711
Cc: teor Actual Points:
Parent ID: #21900 Points: small
Reviewer: Sponsor:

Description

Mar 21 00:11:06 hostnaem Tor[1907]: Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (6)
Mar 21 00:11:06 hostnaem Tor[1907]: set_options(): Bug: Acting on config options left us in a broken state. Dying.

This just happened on my 0.2.7.0-alpha-dev build. resolv.conf contains only a "search" parameter, but no nameservers.

Child Tickets

Attachments (1)

15421-workaround-for-non-exits.diff (2.0 KB) - added by fk 2 years ago.
#15421 workaround for non-exits

Download all attachments as: .zip

Change History (24)

comment:1 Changed 3 years ago by dgoulet

Milestone: Tor: 0.2.7.x-final
Points: small
Priority: normalmajor
Version: Tor: unspecifiedTor: 0.2.7.1-alpha

comment:2 Changed 3 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

Not a security issue or a regression; it doesn't go in after the 0.2.7 freeze.

comment:3 Changed 3 years ago by fk

Severity: Normal

Unfortunately this also affects non-exits which probably should not bother to try to configure nameservers in the first place.

Maybe dns_init() and dns_reset() should check options->ExitRelay instead of server_mode(options)?

BTW, this has been previously reported with a less precise title as #9990.

Changed 2 years ago by fk

#15421 workaround for non-exits

comment:4 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:5 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:6 Changed 19 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:7 Changed 18 months ago by nickm

Cc: teor added
Keywords: tor-relay resolv.conf dns added

See also #21900

comment:8 Changed 18 months ago by teor

Parent ID: #21900

I'll collect all the cases under #21900 so we fix them all at once.
(Or at least we document which are fixed and which are not.)

comment:9 Changed 17 months ago by atagar

Hi there, yesterday I ran into an issue that looks like this too. Here's the repro steps I provided from #23036 with the latest git tip (tor commit bb66a48).

Repro steps:

  • Start system without a network connection.
  • Start tor, torrc I used was...
% cat ~/.tor/torrc 
ControlPort 9051
ExitPolicy reject *:*
  • Set the ORPort with "SETCONF ORPort=9090".

Result:

Tor process terminates with...

Jul 25 19:21:33.000 [warn] ControlPort is open, but no authentication method has been configured.  This means that any program on your computer can reconfigure your Tor.  That's bad!  You should upgrade your Tor controller as soon as possible.
Jul 25 19:21:33.000 [notice] Opening OR listener on 0.0.0.0:9090
Jul 25 19:21:33.000 [notice] You are running a new relay. Thanks for helping the Tor network! If you wish to know what will happen in the upcoming weeks regarding its usage, have a look at https://blog.torproject.org/blog/lifecycle-of-a-new-relay
Jul 25 19:21:33.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because I don't have one. To do that, I need to load (or create) the permanent master identity key. If the master identity key was not moved or encrypted with a passphrase, this will be done automatically and no further action is required. Otherwise, provide the necessary data using 'tor --keygen' to do it manually.
Jul 25 19:21:33.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed 4853AB6F9215A837EA3562CF4AF00713737FDF01'
Jul 25 19:21:33.000 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (6)
Jul 25 19:21:33.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.3.2.0-alpha-dev bb66a48541aa5110)

Cheers! -Damian

comment:10 Changed 17 months ago by teor

Keywords: dos-maybe added
Milestone: Tor: unspecifiedTor: 0.3.3.x-final

This could be a potential DoS risk if DNS goes down for an exit, and it is HUP'ed while DNS its down. It would be nice to get it fixed in the next year or so.

Damian, can you confirm that your system is non-macOS?

comment:11 Changed 17 months ago by atagar

Yup. It's Ubuntu 16.04.

comment:12 Changed 9 months ago by nickm

Keywords: 033-must crash added

comment:13 Changed 9 months ago by nickm

Owner: set to nickm
Status: newaccepted

So current the logic in dns.c:configure_nameservers() is (simplified):

    clear_nameservers();
    if (parse_resolv_conf()) {
        warn();
        goto err;
    }

You can see why this is hard to fix: by the time that we notice that we can't parse resolv.conf, we have already cleared all the old nameservers.

Ideally, what we'd like to have is an safe way to load resolv.conf and replace the current nameservers on success, or do nothing on failure. Libevent's evdns code does not provide this, afaik.

From what I can tell, there are three options here:

  1. Patch libevent to provide an option to do what we want.
  2. When reloading resolv.conf, create a new evdns_base, and only replace the old evdns_base with it if the load is successful. The problem here is that our existing logic assumes that the evdns_base stays the same object forever. I worry that changing this assumption could lead to tricky bugs.
  3. When reloading resolv.conf, first try to create a new dummy evdns_base with the new resolv.conf. Free it immediately. Only if that load succeeds should we try to do the clear-and-replace logic above.

I think option 3 is our best shot for now, even though it has a race condition.

Additionally, we can improve the situation by making this error non-fatal on non-exits, assuming it can still happen there.

comment:14 Changed 9 months ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

To avoid the race condition in 3', we could make a temporary copy of resolv.conf before we start. Ugh!

comment:15 Changed 9 months ago by nickm

Keywords: 033-must crash removed

I am removing the 033-must and deferring this to 034, since it is trickier to get right than I had thought, and it is not a regression.

comment:16 Changed 9 months ago by nickm

Keywords: 034-triage-20180328 added

comment:17 Changed 9 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:18 Changed 8 months ago by nickm

Keywords: 034-included-20180405 034-must security crash added; 034-removed-20180328 removed

comment:19 Changed 7 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: 0.3.5.x-final

comment:20 Changed 5 months ago by nickm

Keywords: 035-removed-20180711 added
Milestone: Tor: 0.3.5.x-finalTor: unspecified

These tickets are being triaged out of 0.3.5. The ones marked "035-roadmap-proposed" may return.

comment:21 Changed 3 months ago by teor

Keywords: 034-must removed

If we removed this ticket from 0.3.4, it can't be 034-must.

comment:22 Changed 6 weeks ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.6.x-final
Resolution: fixed
Status: acceptedclosed

Should be fixed with merge of parent.

comment:23 Changed 5 weeks ago by nickm

Milestone: Tor: 0.3.6.x-finalTor: 0.4.0.x-final

Tor 0.3.6.x has been renamed to 0.4.0.x.

Note: See TracTickets for help on using tickets.