Opened 2 years ago

Closed 2 years ago

Last modified 4 weeks ago

#23249 closed defect (not a bug)

Tor Browser DNS security: hosts file bypassed when "Proxy DNS when using SOCKS v5" is enabled

Reported by: lux+tor@… Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

This is not a bug, rather an unexpected behavior, which might expose the user to more or less severe security concerns.

host table

Operating systems provide a primitive mechanism, called "host table", which is a static lookup table for hostnames, the ancestor of DNS (bind software). Through a configuration file (/etc/hostson Linux, %systemroot%\system32\drivers\etc\hosts on Windows), a system administrator is able to manually set associations of (hostname ; IP_address).

When a user performs a DNS lookup ("I give you a hostname, give me its IP address."), by default, the following procedure occurs (this behavior can be changed on Linux by editing /etc/nsswitch.conffile):

  1. look for hostname in host table
  2. is it here?
    1. yes: return IP address set by administrator
    2. no: perform a "standard" DNS lookup

The host table can be used for security purposes. For instance, if example.org is a domain known for its dangerous behavior (user tracking for instance), a system administrator can block the malicious website by using this/etc/hostsfile:

127.0.0.1 example.org # both IPv4
::1       example.org # and IPv6 must be set!

The host table is widely used by programmers and power users to easily block websites, without having to configure heavier local DNS or firewall.

For more information, please refer to Wikipedia - Hosts (file)

Tor Browser option "Proxy DNS"

Tor Browser provides the option:

"Advanced" → "Network" → "Settings" → "Proxy DNS when using SOCKS v5"

which is equivalent to the "about:config" option:

"network.proxy.socks_remote_dns"

By default, the value is "true" (as I think it should be).

Expected behavior

When typing a hostname (for instance example.org) in the location bar and then pressing the "Go" button (or the "enter" key), Tor Browser will look up for the IP address of example.org.

What is to be expected: the procedure as explained above with the added value of Tor Browser, which is performing the DNS lookup through Tor:

  1. look for hostname in host table
  2. is it here?
    1. yes: return IP address set by administrator
    2. no: perform a "standard" DNS lookup through Tor

Actual behavior

What I got with "Tor Browser 7.0.4 (based on Mozilla Firefox 52.3.0) (64-bit)":

  1. perform a "standard" DNS lookup through Tor

The host table is completely bypassed … Users are exposed to malicious websites.

Actual behavior with "false"

If I set "network.proxy.socks_remote_dns" to "false" and reboot Tor Browser, then I got the procedure as first explained:

  1. look for hostname in host table
  2. is it here?
    1. yes: return IP address set by administrator
    2. no: perform a "standard" DNS lookup (not through Tor as asked and expected)

This proves that Tor Browser is able to look up in the host table! However, it is able to do it only when not using Tor for DNS.

Conclusion

I agree that, blocking a website by its hostname is not completely secure, as a website can own several hostnames. However, it is:

  • a low-cost high-benefit (partial) solution
  • widely used by advanced users (just search for "hosts file" in your search engine)
  • a protection against potentially-severely-malicious-website (containing malwares or spywares)
  • a configure-once-works-for-every-browsers solution

Therefore, I choose a "Major" severity for this ticket.

Child Tickets

Change History (11)

comment:1 Changed 2 years ago by cypherpunks

Component: - Select a componentApplications/Tor Browser
Owner: set to tbb-team
Resolution: not a bug
Status: newclosed

comment:2 Changed 2 years ago by lux+tor@…

This ticket has been closed and marked as solved under the pretext of "not a bug". IMHO, it is an undeserved fate ...

I don't know what is the policy for this bug tracking tool, so maybe I am mistaken. However:

  1. When I sayd "This is not a bug", I meant "Tor Browser does not crash", and not "Tor Browser works as it should".
  2. Some tickets are marked as "enhancement" and are not closed: [https://trac.torproject.org/projects/tor/ticket/21961][https://trac.torproject.org/projects/tor/ticket/664]. If my ticket should not have a "defect" type but rather a "enhancement" type, correcting the type would have been a more appropriate treatment than just closing it. I am new to this tool so, excuse me for the mistake.
  3. I have just found a ~similar~ issue, which has been marked as "MAJOR BUG" in Mozilla support website (https://support.mozilla.org/en-US/questions/1011327).
  4. I spent 1h30 to write this full bug report, with a particular care to readability in order to help your team. At least, just to show some respect, I would have appreciated some explanation as why, even if some may qualify this as a bug, it will not be considered a bug nor converted into an enhancement nor even tested just to check if the problem is duplicable.

I suspect your team to be quite busy, but still ...

Last edited 2 years ago by lux+tor@… (previous) (diff)

comment:3 Changed 2 years ago by cypherpunks

@lux Your ticket was closed by the user cypherpunks who is an open multi-user, it isn't used by Tor Project employees.

If you want this to be seen by Tor Project employees then I may reopen it but I'm reluctant to since that the hosts file should be bypassed is expected behavior. Otherwise it becomes easy to censor sites for the Tor Browser, and since some users use hosts file to block ads (Peter's hosts file for example) then they will become easier for fingerprint. Without even mentioning what proxy bypasses and whatnot may result from such a move.

I'm pretty sure that if you ask on #tor or #tor-dev you'd get roughly the same answer.

Last edited 2 years ago by cypherpunks (previous) (diff)

comment:4 Changed 2 years ago by lux+tor@…

Fingerprint problem

I cannot understand how a website (example1.org) can know that another website (example2.org) is not accessible from this same browser. If such a thing is possible, it may be a real flaw in some protocol or software. However, I am not an expert in fingerprints nor network protocols ...

If, for the sake of the argument, I suppose such an ability is possible, it means there is a conflict between security vs anonymity. Increasing one means decreasing the other. It is quite bad :-(

However, when such kind of a conflict exists (between two desirable qualities), the choice should be given to the user to decide for himself.

In this particular case

The right solution should be a checkbox "Use local hosts file (may increase security at the cost of anonymity)", set to "false" by default.

The alternative solution would be to:

  1. disable "Proxy DNS when using SOCKS v5"
  2. install a firewall
  3. configure the firewall to forward DNS requests into the tor service opened by Tor Browser

It kind of defeats the purpose of (I quote) "Tor Browser lets you use Tor on Microsoft Windows, Apple MacOS, or GNU/Linux without needing to install any software".

Conclusion

As you proposed, I am begging you to please reopen this ticket. I hope it will get the attention it deserves from the dev team.

comment:5 Changed 2 years ago by cypherpunks

Resolution: not a bug
Status: closedreopened

comment:6 Changed 2 years ago by boklm

Resolution: not a bug
Status: reopenedclosed

The hosts file on a system can contain many entries, including some that could cause Tor Browser to do unexpected things, or do not make any sense in the context of using Tor Browser.

One of the main properties in the Tor Browser design is "State Separation":
https://www.torproject.org/projects/torbrowser/design/#security

The browser MUST NOT provide the content window with any state from any other browsers or any non-Tor browsing modes. This includes shared state from independent plugins, and shared state from operating system implementations of TLS and other support libraries.

Using the hosts files to resolve host names would be against that property.

comment:7 Changed 2 years ago by lux+tor@…

Resolution: not a bug
Status: closedreopened

State Separation enforces anonymity

I agree with your point: "State Separation" is definitely something necessary to favour anonymity. Effectively:

  • if Tor Browser and Some-Other-Browser share a same hostsfile
  • if, for the sake of the argument, we suppose that a website is able to get that information through each of the two browsers

then: the website might be able to use this information to narrow down the identity of the user.

The choice anonymity vs security should be left to the user

However, the "State Separation" argument did not disprove mine : "when such kind of a conflict exists [between anonymity and security], the choice should be given to the user to decide for himself".

To convince you, I have an analogy and two examples taken from the (very good!) page you linked.

Analogy

Let say two pieces of equipment are at a person's disposal:

  • a mask: to protect his anonymity
  • a helmet: to protect his security

Let suppose in some cases, the person can't wear both at once. In this case, the equipment supplier cannot determine which one the user should wear, because it depends on the situation. For instance, if the user explores some caves, he might rather have a helmet to protect his head from rocks.

Example 1: "Disk Avoidance"

The "Disk Avoidance" principle states (I quote) :

"The browser MUST NOT write any information ![...] to the disk ![...] unless the user has explicitly opted to"

To rephrase, "Disk Avoidance" is a principle in favour of anonymity, however, if the user choose not to (here it is for another quality, usability), you let him do so.

Example 2: "No filters"

I like this example because the hostsfile is exactly a filter. The "5. No filters" philosophy states (I quote):

"Site-specific or filter-based addons ![...] are to be avoided ![...] Users are free to install these addons if they wish, but doing so is not recommended, as it will alter the browser request fingerprint"

Once again, even if you don't recommend it, you still let the user choose security over anonymity when he thinks it's appropriate.

Conclusion

A complete ban of hostsfile instead of adding a checkbox "Use local hosts file (Not recommended)", unchecked by default, goes against :

  1. which-might-be-wrong-but-still :-p common sense (analogy)
  2. consistency of Tor Browser own policy (example 1 and 2)

Consequently, the hostsfile bypass is an unexpected behaviour, therefore: bug.

I consider this argument quite convincing, but if it still needs a little push, I recommend the reading of the W3C "Priority of Constituencies" principle that any browser implementor should follow.

comment:8 Changed 2 years ago by cypherpunks

Resolution: not a bug
Status: reopenedclosed

comment:9 Changed 2 years ago by cypherpunks

Not bypassing hosts isn't an increase in security.

comment:10 Changed 2 years ago by lux+tor@…

This will be my last reply.

I've spent almost a day and a half lost in the (vain) attempt to use reason to prove a sound argument, only to get a response similar to "No you're wrong. No reason.". I am quite disappointed ... ("Don't meet your heroes" I guess)

Had I not tried to do the right thing (convince people so they can be right + correct a pretty good software so that it could work as expected), I would already have a viable workaround by now.

What follows is for :

  1. the undecided people: to help them come to the right conclusion (until rationally disproved)
  2. the decided people: to give them a lead on how to do a workaround

(for the undecided) Using hosts file might increase security

The answer was : "Not bypassing hosts isn't an increase in security."

My english is not so good and two negations is too much for a positive person like me ;-). I suppose it means "No use of hostsfile increases security".

Some very rough definitions:

  • security: protection against risk
  • risk: probability x negativity
  • negativity: something bad. Losing $$ is a financial negativity. Getting sick is a health negativity. Being identified is an anonymity negativity.

So, security is what reduces the probability of risk or reduces the negativity (the quantity of $$ you lose).

This example is taken from my own history. Once upon a time (^_^), I tried to buy something on internet. The website I've found proposed what I wanted, and for a very good price. I paid, with my credit card, but I received nothing. The website was a scam. I was sad. I added this website inside my hostsfile. A long time after, I searched for completely something else, the search engine gave me a result that gave the impression to fit, but I could not access the website. After some investigation, the website was blocked by my hostsfile: it was the very same website that had stole me once. The hosts file prevented me from losing some $$! (What a hero!)

QED

(for the decided) Workaround to use both Tor and hosts file

Warning: for those who jumped to this section without reading the rest, it is not recommended by Tor Browser team!

I already spent too much time on this issue, so I will only give a lead.

If you want the security provided by the hostsfile and still have some pretty-good (but suboptimal) anonymity, you might want to:

  • route your DNS requests through Tor: this article (tuxdiary.com/2015/11/16/resolve-dns-tor/) seems quite good
  • configure your Tor Browser with "Edit" menu / "Preferences" / "Advanced" / "Network" / "Settings" / uncheck "Proxy DNS when using SOCKS v5"

How it works? By configuring Tor Browser this way, it will use the local mechanism to solve hostnames: by default hostsfile then DNS. As your DNS requests go through Tor Browser's Tor service, it's good.

What is bad? If I wanted this matter solved the right way, it is for a good reason: with the workaround just proposed, the problem is that every DNS requests go through Tor, even the DNS requests of other softwares (which might break the "State Separation" principle as explained earlier). It also means that Tor Browser has to be always running (-_-).

If you want something that does not go through Tor Browser's Tor service:

  • configure this Tor service to use a different port (other than 9050), by editing the torrcfile (Linux: /etc/torrc)
  • route your DNS requests through this Tor service (and not through the Tor service alongside Tor Browser): this article (tuxdiary.com/2015/11/16/resolve-dns-tor/) still seems quite good
  • configure your Tor Browser with "Edit" menu / "Preferences" / "Advanced" / "Network" / "Settings" / uncheck "Proxy DNS when using SOCKS v5"

This workaround is cleaner but needs more work ...

comment:11 Changed 4 weeks ago by rulatir

[nevermind]
Also this Trac configuration VIOLENTLY SUCKS. Enable deleting comments by authors for fuck's sake!!!

Last edited 4 weeks ago by rulatir (previous) (diff)
Note: See TracTickets for help on using tickets.