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

The fix for #10419 (closed) 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.

added component::applications/tor browser owner::tbb-team priority::medium severity::normal status::new tbb-firefox-patch type::defect labels

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

Trac:
Cc: N/A to gk

Read comment #10419 (closed).

Don't surf localhost over proxy, please!

Replying to cypherpunks:

Read comment #10419 (closed).

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?

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.

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

Trac:
Username: oc
Cc: gk to gk, o.cornu@riseup.net

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

Trac:
Description: #10419 (closed) is not fixed, fix for #10419 (closed) creates security hole.

to

The fix for #10419 (closed) 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.
Summary: Revert #10419 (closed) and fix it by another way to Block 127.0.0.0/8, RFC1918, and others ranges (for Non-Tor SOCKS proxies)
Keywords: tbb-fingerprinting, MikePerry201401R, tbb-pref deleted, N/A added
Priority: blocker to normal

The fix for #10419 (closed) 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 (closed) 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.

Sending 127.0.0.1 requests to Tor was a quick fix for #10419 (closed) 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 (closed) 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 (closed), if they worked as intended. My guess is: the path to make them work starts with addressing #10854 (moved).

Trac:
Username: oc

Replying to oc:

The right fix for #10419 (closed) 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.

Trac:
Owner: mikeperry to tbb-team
Keywords: N/A deleted, tbb-firefox-patch added
Component: Firefox Patch Issues to Tor Browser

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

mentioned in issue #10840 (moved)

moved to tpo/applications/tor-browser#10839 (closed)