Bug #13574

localhost.localdomain DNS lookup leaks to Tor circuits

Added by tailshark 2017-08-03 18:18:19 . Updated 2017-09-28 18:48:38 .

Status:
Resolved
Priority:
High
Assignee:
Category:
Target version:
Start date:
2017-08-03
Due date:
% Done:

100%

Feature Branch:
https://gitlab.com/tailshark/tails/commits/bugfix/13574-etc-hosts-localhost-localdomain-loopfix
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Hi,

Since switching to Stretch I noticed odd activity that would come up in Tor circuits when first connecting to the Tor network. Sometimes (not always - exact conditions unknown) there will be visible entries of localhost.localdomain:0 shown as coming out at the Tor exit in the OnionCircuits display.

I’m guessing (have not confirmed) that something that has been upgraded is making localhost.localdomain DNS lookup requests and instead of being intercepted/filtered/handled at the /etc/hosts file it’s going into the DNS resolver and out of the connected circuits.

Right now the /etc/hosts file reads as:
——
127.0.0.1 localhost amnesia
——

It should probably read as:
——
127.0.0.1 localhost localhost.localdomain amnesia
::1 localhost localhost.localdomain amnesia
——

My guess is that something does a “hostname” or “hostname -f” request and gets back “localhost.localdomain” response which fires at the DNS resolver which may or may not be connected yet. If it’s not connected yet things may continue without anything noticable in OnionCircuits whereas if the connection process is quicker there is a localhost.localdomain:0 set of requests fired down the circuits.

One obvious concern here is the Tor exit actually responding and provides an IP other than 127.0.0.1 causing localhost communication to actually try to resolve to a foreign server. Hopefully the existing firewall would intercept that (if the app making the requests is not the Tor process it should intercept that) and prevent a rather grave data leak. It has the potential to be disastrous but I don’t think it actually is with the present security configuration.

Best I can figure… an evil Tor exit could potentially redirect your traffic on your LAN with a bunk DNS resolution but given they don’t actually know where you are that (again) doesn’t seem like an immediate threat.

I’ll put the information out there and let you decide if it should be escalated.


Files


Subtasks


Related issues

Related to Tails - Bug #15322: Many firewall rejection logs during early boot due to localhost.localdomain DNS lookups Resolved 2018-02-18
Blocks Tails - Bug #13598: Slow opening of files with vi Resolved 2017-08-06

History

#1 Updated by tailshark 2017-08-03 18:37:20

UPDATE:

I have confirmed the lookup is reproducible (at least here) if you do a “service tor restart” as root. The connections seem to come up quicker and more reliably show the bug.

I have also confirmed that my proposed patch seems to eliminate the problem.

#2 Updated by emmapeel 2017-08-03 21:27:14

  • Private changed from No to Yes

I have no idea about this. Making it private by the time being, and making foundations team watchers.

Foundation team:

please open it up if you think it is better.

#3 Updated by tailshark 2017-08-03 22:36:40

Just a thought on a way this could be exploited: The Tor exit could respond by saying, “Hi! I’m localhost.localdomain at port 0 and here’s your data!” —- If it’s commonly happening to Tails systems when connecting it could be a way to target Tails users specifically. Whatever app is making the requests would still have to be exploitable to take advantage of that but that’s still obviously way too close for comfort.

#4 Updated by tailshark 2017-08-04 11:45:58

I dug up where the /etc/hosts file is actually set in Tails. It looks like it’s here:
—————-
/lib/live/config/9000-hosts-file
—————-

Or the repo location of:
—————-
root/config/chroot_local-includes/lib/live/config/9000-hosts-file
—————-

The code there mentions the lack of an ipv6 entry to block ipv6 traffic. Is that accurate or would it lead to the opposite where ipv6 loopback traffic attempts to resolve with the DNS resolver rather than binding locally (leading to a potential ipv6 DNS Tor leak)?

#5 Updated by tailshark 2017-08-04 12:17:04

Answered my own question by testing an apt-get update. Apparently that is correct that ipv6 entry causes apt to fail.

#6 Updated by tailshark 2017-08-04 12:54:47

Proposed patch:
===
#!/bin/sh

  1. Note: must run after /lib/live/config/0020-hostname since it
  2. otherwise will overwrite any hosts file generated at build time with
  3. a bloated one that also include the IPv6 host `::1 localhost`, which
  4. can lead to IPv6 traffic, which we block, which may lead to stuff
  5. breaking (for instance APTs tor+http transport).

echo “- setting up hosts file”
. /etc/live/config.d/hostname.conf

cat > /etc/hosts << EOF
127.0.0.1 localhost localhost.localdomain ${LIVE_HOSTNAME}
EOF
===

To file: /config/chroot_local-includes/lib/live/config/9000-hosts-file

#7 Updated by tailshark 2017-08-04 12:57:56

Sorry, this forum ate the text.

I’ve attached the proposed patched file.

#8 Updated by tailshark 2017-08-04 13:06:27

Corrected version attacged. Last one got an extra period in it somehow.

#9 Updated by sajolida 2017-08-06 16:26:54

  • related to Bug #13598: Slow opening of files with vi added

#10 Updated by tailshark 2017-08-06 16:37:16

I’m new to the way things are done here and am trying to follow protocol. I have forked the repo and performed a patch there.

Patch details are as follows:

=

The following changes since commit da894deb09757313702b3c776fccbade5e2dcc57:

Updating trace file after uploading 3.0 to 3.1 IUK. (2017-08-06 12:43:54 +0200)

are available in the git repository at:

git@gitlab.com:tailshark/tails.git

for you to fetch changes up to d211341466643bd95a5abee50b5fd37b412317a7:

Fixed spelling mistake. (2017-08-06 16:09:04 +0000)


tailshark (2):
localhost.localdomain added to prevent loopback leaks to Tor circuits
Fixed spelling mistake.

config/chroot_local-includes/lib/live/config/9000-hosts-file | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)

=

#12 Updated by intrigeri 2017-09-01 11:59:42

  • Status changed from New to In Progress
  • Assignee set to anonym
  • Target version set to Tails_3.2

Apparently Help Desk didn’t triage this yet, but it seems we should take it seriously. anonym, can you take care of it as part of your Foundations Team work? Note Bug #13598.

#13 Updated by intrigeri 2017-09-07 06:47:14

  • Priority changed from Normal to High
  • % Done changed from 0 to 10
  • Private changed from Yes to No
  • QA Check set to Ready for QA
  • Feature Branch set to https://gitlab.com/tailshark/tails/commits/bugfix/13574-etc-hosts-localhost-localdomain-loopfix

(The fix is public and the issue was raised on Bug #13598 (public too) already => making this ticket public as well. There’s a proposed branch => Ready for QA. It seems to be a potentially important security issue => High priority.)

#14 Updated by intrigeri 2017-09-07 06:48:28

  • related to deleted (Bug #13598: Slow opening of files with vi)

#15 Updated by intrigeri 2017-09-07 06:48:36

  • blocks Bug #13598: Slow opening of files with vi added

#16 Updated by anonym 2017-09-13 13:41:49

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 10 to 100
  • QA Check changed from Ready for QA to Pass

Thanks for your contribution, tailshark! \o/

#17 Updated by anonym 2017-09-28 18:48:38

  • Status changed from Fix committed to Resolved

#18 Updated by intrigeri 2018-02-18 07:20:33

  • related to Bug #15322: Many firewall rejection logs during early boot due to localhost.localdomain DNS lookups added