Opened 2 years ago

Closed 23 months ago

#5741 closed defect (fixed)

TBB proxy bypass: Some DNS requests not going through Tor

Reported by: cypherpunks Owned by: mikeperry
Priority: blocker Milestone:
Component: Firefox Patch Issues Version:
Keywords: MikePerry201205 Cc: g.koppen@…, mikeperry, StrangeCharm, tails@…, mk@…
Actual Points: 3 Parent ID:
Points: 3

Description

Observed behaviour:

When visiting certain websites, for example "http://bitcoincharts.com", with JavaScript enabled, a DNS request for the domain is made without going through Tor. This website is the only one I know of there it happens. This is when running the latest Tor Browser Bundle, properly verified against the gpg signature.

Enabling NoScript to block all JavaScript seems to make the DNS request go away. This was verified by restarting Tor and then disabling JavaScript before visiting the site.

Expected behaviour:

No DNS request should be made through the normal internet, everything should go through Tor. The DNS requests leak information of which sites you are browsing in your Tor Browser.

How to reproduce:

  1. Download and verify "tor-browser-gnu-linux-i686-2.2.35-10-dev-en-US.tar.gz"
  2. Start up Wireshark to monitor your network, optionally filtering for "dns"
  3. Unpack Tor and start it by running the "start-tor-browser" script
  4. Once TorBrowser is open, go to "http://bitcoincharts.com/"
  5. See DNS request for "bitcoincharts.com" being logged in Wireshark

System information:

Tor Browser Bundle for 32-bit Linux, version 2.2.35-10
Running on Fedora 16

Other:

This is not the first time some rarely triggered bug in Firefox causes Tor to be bypassed, and certainly will not be the last one. Since these bugs have a very high security impact I propose they are guarded against. How about running Firefox inside some kind of firewall that drops all network packets not going to Tor?

Child Tickets

Change History (27)

comment:1 Changed 2 years ago by gk

  • Cc g.koppen@… added

comment:2 Changed 2 years ago by gk

I can confirm this. What a nightmare.

comment:3 Changed 2 years ago by rransom

  • Cc mikeperry added
  • Priority changed from critical to blocker

comment:4 Changed 2 years ago by rransom

Could be WebSockets:

		<script type="text/javascript" src="/static/CACHE/js/8d58f66759d3.js"></script>
		<script type="text/javascript">
			var cs = new ChartSocket(null, 8001);
			jQuery(document).ready( cs.connect );
                        if(parent != null && parent != self) {if(parent.location.hostname != self.location.hostname) {top.location.href=self.location.href; }}
		</script>

comment:5 Changed 2 years ago by mikeperry

Good catch Robert. Disabling about:config pref network.websocket.enabled prevents it from happening for me... I'm now grepping through the Firefox WebSocket code looking for the issue..

comment:6 in reply to: ↑ description ; follow-up: Changed 2 years ago by arma

Replying to cypherpunks:

This is not the first time some rarely triggered bug in Firefox causes Tor to be bypassed, and certainly will not be the last one. Since these bugs have a very high security impact I propose they are guarded against. How about running Firefox inside some kind of firewall that drops all network packets not going to Tor?

It would be great to see some very simple instructions for launching Tails in a VM in Windows.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 2 years ago by mikeperry

Replying to arma:

Replying to cypherpunks:

This is not the first time some rarely triggered bug in Firefox causes Tor to be bypassed, and certainly will not be the last one. Since these bugs have a very high security impact I propose they are guarded against. How about running Firefox inside some kind of firewall that drops all network packets not going to Tor?

It would be great to see some very simple instructions for launching Tails in a VM in Windows.

I thought tails stopped shipping with a catch-all/drop-all transproxy rule?

comment:8 in reply to: ↑ 7 ; follow-ups: Changed 2 years ago by rransom

Replying to mikeperry:

Replying to arma:

Replying to cypherpunks:

This is not the first time some rarely triggered bug in Firefox causes Tor to be bypassed, and certainly will not be the last one. Since these bugs have a very high security impact I propose they are guarded against. How about running Firefox inside some kind of firewall that drops all network packets not going to Tor?

It would be great to see some very simple instructions for launching Tails in a VM in Windows.

I thought tails stopped shipping with a catch-all/drop-all transproxy rule?

Tails now drops all outgoing packets whose destination IP address is not RFC-1918 private. Tails stopped using transparent proxy configuration in order to try to keep random crap on the system from linking the user's web-browsing activities, but still configures Tor as the GNOME default SOCKS proxy, which defeats most of that purpose.

Tails 0.10.1 allowed traffic to/from RFC-1918 private addresses; I don't know whether Tails 0.11 does.

comment:9 Changed 2 years ago by mikeperry

Back to the topic at hand: It looks like WebSocketChannel::ApplyForAdmission() is our culprit.

Websockets has a policy of 1 session at a time being allowed in the
CONNECTING state per server IP address (not hostname)

What a joke. I'm really tempted to make this always return NS_OK.

I did a quick audit for other sources of DNS leaks in the rest of the Firefox source tree and did not find any (unless there are hardcoded platform specific haxx, but it looks like everything runs through nsDNSService, which in turn relies on nsHostResolver).

comment:10 follow-up: Changed 2 years ago by mikeperry

https://tools.ietf.org/html/rfc6455#page-15. Am I the only one that thinks this is rather retarded? Can't you perform as many concurrent XMLHTTPRequests/img src/whatevs as you like?

comment:11 in reply to: ↑ 10 Changed 2 years ago by rransom

Replying to mikeperry:

Can't you perform as many concurrent XMLHTTPRequests/img src/whatevs as you like?

Can those be forced onto separate TCP or TLS connections by client-side gunk?

comment:12 Changed 2 years ago by mikeperry

  • Actual Points set to 3
  • Keywords MikePerry201205 added
  • Points set to 3
  • Resolution set to fixed
  • Status changed from new to closed

This is fixed and pushed to all TBB branches. I fixed it by blocking all DNS requests while socks_remote_dns is enabled, so we don't end up with this showing up in new components in the future.

Interested folks can review the patch here: https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0018-Prevent-WebSocket-DNS-leak.patch

comment:13 Changed 2 years ago by mikeperry

By the way, if anyone wants to write a minimal WebSocket test case to guard against future regressions, and to make sure our builds actually properly include the patch, that would be really awesome.

Please attach it to #5292 or a child ticket.

comment:14 Changed 2 years ago by rransom

  • Cc StrangeCharm added

comment:15 follow-up: Changed 2 years ago by arma

I hope somebody has filed the bug with upstream (Mozilla) too?

comment:16 Changed 2 years ago by mikeperry

Half the time I can't access the mozilla bugzilla over Tor. This is one of those times.

comment:17 in reply to: ↑ 15 Changed 2 years ago by gk

Replying to arma:

I hope somebody has filed the bug with upstream (Mozilla) too?

I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=751465

comment:18 Changed 2 years ago by unknown

This is not the first time some rarely triggered bug in Firefox causes Tor to be bypassed, and certainly will not be the last one. Since these bugs have a very high security impact I propose they are guarded against. How about running Firefox inside some kind of firewall that drops all network packets not going to Tor?

You can prevent any potential DNS-leakage with iptables (Debian GNU/Linux way):

Edit /etc/login.defs, Replace "ENCRYPT_METHOD DES" to "ENCRYPT_METHOD SHA-512"

Run command for create tbb-group with password:

addgroup --system tbb-tor

Add this rules to your firewall:

#tor anonymous users;

DIRECT_OUT_GID="tbb-tor" #group id for TBB

TOR_UID="debian-tor" #system tor (if you use it)

#anonymous user runs programs with transparent torification to system tor
#(if you use it):

$IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner anonymoususer ! --gid-owner $DIRECT_OUT_GID -m tcp --syn  -j REDIRECT --to-ports 9040
$IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner anonymoususer ! --gid-owner $DIRECT_OUT_GID -m udp --dport 53 -j REDIRECT --to-ports 53
$IPTABLES -t nat -A OUTPUT -m owner --uid-owner anonymoususer ! --gid-owner $DIRECT_OUT_GID  -j DNAT --to-destination 127.0.0.1

#Accept output for system-tor itself (if you use it)
$IPTABLES -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT

#Direct output for TBB without udp and tcp 53 port
$IPTABLES -A OUTPUT -m owner  --gid-owner $DIRECT_OUT_GID ! -p tcp -j REJECT
$IPTABLES -A OUTPUT -m owner  --gid-owner $DIRECT_OUT_GID -p tcp --dport 53 -j
REJECT
$IPTABLES -A OUTPUT -m owner  --gid-owner $DIRECT_OUT_GID -j ACCEPT

Run your tor-browser with sg from x-terminal emulator:

sg tbb-tor -c start-tor-browser.sh

Unfortunately, this is not an ideal solution for transparent torification TBB. All (but udp and dns-tcp) tcp trafic goes away. Using unix groups is not a way to separate start-script, vidalia, browser and TBB-tor itself. A ticket with more fine-tuned firewall solution is still desirable

comment:19 follow-up: Changed 2 years ago by cypherpunks

I tested and the TBB AppArmor profile also blocks this bug: https://trac.torproject.org/projects/tor/wiki/doc/AppArmorForTBB

comment:20 in reply to: ↑ 19 Changed 2 years ago by cypherpunks

Replying to cypherpunks:

I tested and the TBB AppArmor profile also blocks this bug: https://trac.torproject.org/projects/tor/wiki/doc/AppArmorForTBB

Correction: I forgot had removed the 'network dgram;' allow line from my profile when I first read the tor-talk post. You obviously need to do that for the profile to protect you from UDP leaks like DNS. Also note the tor-talk post says the profile explicitly does *not* protect you from TCP leaks due to AppArmor limitations, so perhaps firewall rules are still needed for proper defense in depth.

comment:21 follow-up: Changed 2 years ago by mikeperry

For people who use layered defenses: Please add iptables rules/AppArmor rules/whatever rules that LOG violations so we can learn about them. We are desperately in need of testers and auditors so this never happens in production again. See also #3846 and consider signing up to test builds in your hardened, auditing setups.

comment:22 in reply to: ↑ 21 Changed 2 years ago by unknown

Replying to mikeperry:

For people who use layered defenses: Please add iptables rules/AppArmor rules/whatever rules that LOG violations so we can learn about them.

I check following corrected steps:

Prevent and LOG any potential DNS-leakage with iptables (Debian GNU/Linux way)

Edit /etc/login.defs, replace "ENCRYPT_METHOD DES" to "ENCRYPT_METHOD SHA-512"
#default DES is equivalent to 8-symbols passwords for groups and insecure

Run command for create system tbb-group with password and without shell:

addgroup --system tbb-tor

Check that you use rsyslog and not a syslog daemon:

dpkg -L rsyslog

or install it:

apt-get install rsyslog

Create a file /etc/rsyslog.d/iptables.conf with the following contents:

:msg, contains, "iptables" -/var/log/iptables.log
& ~

Create a file /etc/logrotate.d/iptables with the following contents:

/var/log/iptables.log{

    daily
    rotate 5
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        invoke-rc.d rsyslog reload > /dev/null
    endscript

}

Restart syslog:

/etc/init.d/rsyslog restart

Add this rules to your firewall script and restart it:

$IPTABLES -t nat -A OUTPUT -o lo -j RETURN
$IPTABLES -t nat -A OUTPUT -d 127.0.0.1 -j RETURN

#tor anonymous users;

DIRECT_OUT_GID="tbb-tor" #group id for TBB

TOR_UID="debian-tor" #system tor (if you use it)
# with options:
# AutoMapHostsOnResolve 1
# TransPort 9040
# DNSPort 53

ANONYMOUS_UID="toranonymoususer" #if you use anonymous transparent torification to system tor

#anonymous user runs programs with transparent torification to system tor
#(if you use it):

$IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner $ANONYMOUS_UID ! --gid-owner $DIRECT_OUT_GID -m tcp --syn  -j REDIRECT --to-ports 9040
$IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner $ANONYMOUS_UID ! --gid-owner $DIRECT_OUT_GID -m udp --dport 53 -j REDIRECT --to-ports 53

$IPTABLES -t nat -A OUTPUT -m owner --uid-owner $ANONYMOUS_UID ! --gid-owner $DIRECT_OUT_GID  -j LOG --log-prefix "iptables $ANONYMOUS_UID redirect" #some potential leakages redirected to localhost and  not going away
$IPTABLES -t nat -A OUTPUT -m owner --uid-owner $ANONYMOUS_UID ! --gid-owner $DIRECT_OUT_GID  -j DNAT --to-destination 127.0.0.1

#Accept output for system-tor itself (if you use it)
$IPTABLES -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT

#Direct output for TBB without udp and tcp 53 port
$IPTABLES -A OUTPUT -m owner  --gid-owner $DIRECT_OUT_GID ! -p tcp -j LOG --log-prefix "iptables tbb reject: "
$IPTABLES -A OUTPUT -m owner  --gid-owner $DIRECT_OUT_GID ! -p tcp -j REJECT

$IPTABLES -A OUTPUT -m owner  --gid-owner $DIRECT_OUT_GID -p tcp --dport 53 -j LOG --log-prefix "iptables tbb reject: "
$IPTABLES -A OUTPUT -m owner  --gid-owner $DIRECT_OUT_GID -p tcp --dport 53 -j REJECT

$IPTABLES -A OUTPUT -m owner  --gid-owner $DIRECT_OUT_GID -j ACCEPT

Run tor-browser with sg from x-terminal emulator:

sg tbb-tor -c start-tor-browser.sh

Watch /var/log/iptables.log with your favorite parser.

comment:23 in reply to: ↑ 8 Changed 2 years ago by T(A)ILS developers

  • Cc tails@… added

Replying to rransom:

Tails 0.10.1 allowed traffic to/from RFC-1918 private addresses; I don't know whether Tails 0.11 does.

For the record, both allow traffic to RFC-1918 addresses. I don't think Tails has ever allowed incoming connections from the outside of the system.

comment:24 in reply to: ↑ 8 Changed 2 years ago by mk

  • Cc mk@… added

Replying to rransom:

Tails now drops all outgoing packets whose destination IP address is not RFC-1918 private. Tails stopped using transparent proxy configuration in order to try to keep random crap on the system from linking the user's web-browsing activities, but still configures Tor as the GNOME default SOCKS proxy, which defeats most of that purpose.

No, Tails stopped using transparent proxying mainly due to the danger of an application accidentally transmitting the IP address of the external interface the application is bound to. Defining an unneeded explicit proxy is undesirable, but orders of magnitude less dangerous.

comment:25 Changed 23 months ago by mikeperry

  • Component changed from Tor bundles/installation to Firefox Patch Issues
  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:26 Changed 23 months ago by mikeperry

  • Owner changed from erinn to mikeperry
  • Status changed from reopened to assigned

Stupid trac makes me reopen a ticket to give it the correct owner...

comment:27 Changed 23 months ago by mikeperry

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.