pseudo-flaw.net

Tor (The Onion Router) version 0.1.2.19 has been released. Download it here.

The release notes make mention of one security fix:

Exit policies now reject connections that are addressed to a relay's public (external) IP address too, unless ExitPolicyRejectPrivate is turned off. We do this because too many relays are running nearby to services that trust them based on network address.

The fix addresses an issue most recently discussed on the or-talk mailing list. Martin Fink posted a message Security concerns/help me understand tor that raised the issue of cheap home routers that provide access control based on LAN IP address ranges. The basic premise is that if a Tor exit node is NAT'd behind a cheap home router, any ports listening on the LAN side of the router may be exposed to Tor traffic. This situation arises for a couple of reasons.

The first reason is due to nature of Internet routing. In a typical home network, packets destined for the external IP address of the gateway router that originate within the home network will be routed directly to the gateway router. These packets will arrive on the LAN interface even though they are addressed to the external IP address. If the router is performing authorization based on either packet source address or the interface the packet arrived on, it will appear as if this is legitimate LAN traffic. This holds true of any proxy-type systems that are deployed on an internal network but accept traffic from an external source.

The second reason is that Tor attempts to solve the exit node eavesdropper problem by detecting if you going to IP address that also has a Tor exit node running on it. If it detects this situation, Tor will construct a routing path that terminates at that IP address. The OnionRouterFAQ has an entry that describes this:

Tor does provide a partial solution in a very specific situation, though. When you make a connection to a destination that also runs a Tor relay, Tor will automatically extend your circuit so you exit from that circuit. So for example if Indymedia ran a Tor relay on the same IP address as their website, people using Tor to get to the Indymedia website would automatically exit from their Tor relay, thus getting *better* encryption and authentication properties than just browsing there the normal way.

But, that behavior combined with a NAT'd Tor server behind a cheap home router raises an interesting problem.

For example, consider home network router with an external IP address of 77.77.77.77 and an internal IP address of 192.168.0.1, and a Tor server NAT'd at 192.168.0.69. If Tor detects that a web user wants to visit the web page at IP address 77.77.77.77, the onion routing path will be constructed to exit at that IP address. When the Tor server running on 192.168.0.69 receives a packet to be routed to 77.77.77.77, it will treat it just like any other packet to exit. The server will unencrypt it and forward it out. But since the Tor server is NAT'd to 192.168.0.69, when the packet is forwarded to the gateway router, it will be receiving it on the LAN interface. If that LAN interface has a web server listening on it, that web server will respond. What if this is the administrative interface for the router and access restrictions are based on the origin of the packet? Any Tor user (that wanted to) could browser to the admin interface of the router and reconfigure it.

In general, Tor attempts to guard against routers sending locally addressed packets by automatically adding exit policy deny rules for the RFC 1918 address space. The 0.1.2.19 update adds a deny rule to the exit policy for the external IP address of the Tor server. If the old behavior is desired, it would need to be configured manually.

The change is important for those home users who don't understand the intricacies of network routing or use cheap gear that trusts packets based on where they originate. But given the relative prevalence of client-side browser exploits, that trust is probably misplaced to begin with.