Opened 6 years ago

Last modified 2 years ago

#10839 new defect

Block 127.0.0.0/8, RFC1918, and others ranges (for Non-Tor SOCKS proxies)

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-firefox-patch
Cc: gk, o.cornu@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by mikeperry)

The fix for #10419 was Tor specific. We rely on Tor blocking localhost, RFC1918, and other non-routable addresses to prevent these requests from going anywhere.

This creates problems for people who want to use Tor Browser with non-Tor SOCKS proxies. The browser will now try to proxy localhost, and it will still continue to proxy RFC1918 addresses, as it did before.

This is not a development priority for us, but we will accept a patch that prevents localhsot, RFC1918, and other internal address space from being proxied in the first place.

Child Tickets

Change History (12)

comment:1 Changed 6 years ago by gk

Cc: gk added

What is the security hole you are talking about? How does the attack you have in mind work?

comment:2 Changed 6 years ago by cypherpunks

Read comment #10419.

Don't surf localhost over proxy, please!

comment:3 in reply to:  2 Changed 6 years ago by gk

Replying to cypherpunks:

Read comment #10419.

I did but I have a hard time understanding your threat model. So, you say one cannot trust 127.0.0.1 and should therefore not be allowed trying to reach it?

comment:4 Changed 6 years ago by cypherpunks

Block connection to localhost != pass local connection over proxy lets it decide what to do.
Torbrowser using Tor but is't not Tor, lets do not create security holes for browser hoping Tor can fix it.

comment:5 Changed 6 years ago by cypherpunks

threat model

Threat model is simple. Lets create every module for bundle as much secure as possible.

comment:6 Changed 6 years ago by oc

Cc: o.cornu@… added

comment:7 Changed 6 years ago by mikeperry

Description: modified (diff)
Keywords: tbb-fingerprinting tbb-pref MikePerry201401R removed
Priority: blockernormal
Summary: Revert #10419 and fix it by another wayBlock 127.0.0.0/8, RFC1918, and others ranges (for Non-Tor SOCKS proxies)

I agree this is an issue, but it is not a high development priority for us.

comment:8 Changed 6 years ago by cypherpunks

The fix for #10419 was Tor specific.

Tor specific is to block all localhost, RFC1918, and other non-routable addresses in first place, so Tor didn't warn user.

This is not a development priority for us

#10419 not even fixes what it was should be fixed for all Tor specific cases. Proxying localhost can't fix fingerprint if used Tor specific transparent proxying.

I can't get why you can't get this vuln. No even fix in result, just security hole in general Torbrowser implementation.

comment:9 Changed 6 years ago by oc

Sending 127.0.0.1 requests to Tor was a quick fix for #10419 in a default TBB context. Everything is now sent to the Tor proxy, which by default filters out private IP address ranges defined in tor_addr_is_internal_() (unless you have manually unset the ClientRejectInternalAddresses config flag).
This was by far the biggest threat, as I believe the Tor browser is mainly used as a TBB component (not as a standalone app).

It sure isn't the best fix ever, though:

  • It is not a good fix if you use the Tor browser with another random proxy.
  • It is not a good fix if you use it with the Tor proxy and unset ClientRejectInternalAddresses (your localhost requests will be forwarded on the network).
  • It is not a good fix even if you keep this flag set: localhost becomes unreachable (as every other "internal" address).

The right fix for #10419 is not to block localhost, as you propose: localhost is not a threat.
At least, blocking localhost in a TBB context makes some sense: TBB is not designed to browse localhost. In a standalone Tor browser context though, blocking localhost does not make sense: why would a secure browser refuse to browse the safest place on the Internet? Thus blocking it is yet another quick hack to avoid dealing with the real threat: localhost <-> !localhost communication of any kind.

Therefore, if you're really eager to fix this properly, you should submit a Tor browser patch that allows to browse localhost without leaking requests on the wire, and to browse other web pages without leaking requests to localhost in any way (XHR, HTML tags, etc).
In other words, something like the ABE rule sets presented in #10419, if they worked as intended. My guess is: the path to make them work starts with addressing #10854.

Last edited 6 years ago by oc (previous) (diff)

comment:10 in reply to:  9 Changed 6 years ago by gk

Replying to oc:

The right fix for #10419 is not to block localhost, as you propose: localhost is not a threat.

Yes. The right solution is fixing https://bugzilla.mozilla.org/show_bug.cgi?id=354493. Patches welcome.

comment:11 Changed 5 years ago by erinn

Component: Firefox Patch IssuesTor Browser
Keywords: tbb-firefox-patch added
Owner: changed from mikeperry to tbb-team

comment:12 Changed 2 years ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.