Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#6710 closed defect (fixed)

Tor Relays accept arbitrary destination address and port and leak information about reachability

Reported by: thejh Owned by:
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor relays accept arbitrary destination address-port-combinations, including RFC1918 addresses, in EXTEND commands, and leak information about reachability. Here's a little, unreliable, pretty much broken PoC: https://github.com/thejh/tor/compare/master...fake_relay

Usage: Configure the target relay as bridge, set loglevel to notice and run the modified tor client with some IP and port in the bridges network as last two parameters (for some reason, it seems like the IP has to be in backwards notation... don't ask me why).

Example:
$ src/or/tor -f torrc 1.178.168.192 80
[...]
Aug 27 10:30:34.000 [notice] CREATING SPOOFED CIRCUIT
Aug 27 10:30:34.000 [notice] CIRCUIT WAS DESTROYED

$ src/or/tor -f torrc 2.178.168.192 80
[...]
Aug 27 10:30:00.000 [notice] CREATING SPOOFED CIRCUIT
Aug 27 10:30:03.000 [notice] CIRCUIT WAS DESTROYED

192.168.178.1 is up, 192.168.178.2 is down. As you can see, the response time reflects this.

If there are firewalls that DROP traffic to ports that aren't witelisted, it might even be possible to scan them to figure out which ports are whitelisted, thereby figuring out operating system and network structure details.

Also, it might be possible to extend this attack if the relay uses global IP sequence numbers - opening a TCP connection, exchanging packets and closing it certainly takes more IP packets than one SYN packet, right? This would mean that a variant of idle scanning could be used.

Child Tickets

Change History (12)

comment:1 Changed 7 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.3.x-final
Priority: normalmajor
Status: newneeds_review

The best/easiest fix for the worst part of this is probably just to reject EXTEND cells to private addresses. The rest of this (where you probe a router's TCP state or firewall cfg by asking it to extend different places) is probably no so easy, or *as* critical.

I've got a patch in branch bug6710_023 in my public repository that should go into 0.2.3.x after review. We should consider a backport to 0.2.2.

comment:2 in reply to:  description Changed 7 years ago by rransom

Replying to thejh:

Usage: Configure the target relay as bridge, set loglevel to notice and run the modified tor client with some IP and port in the bridges network as last two parameters (for some reason, it seems like the IP has to be in backwards notation... don't ask me why).

You left out a call to htonl.

Example:
$ src/or/tor -f torrc 1.178.168.192 80
[...]
Aug 27 10:30:34.000 [notice] CREATING SPOOFED CIRCUIT
Aug 27 10:30:34.000 [notice] CIRCUIT WAS DESTROYED

$ src/or/tor -f torrc 2.178.168.192 80
[...]
Aug 27 10:30:00.000 [notice] CREATING SPOOFED CIRCUIT
Aug 27 10:30:03.000 [notice] CIRCUIT WAS DESTROYED

192.168.178.1 is up, 192.168.178.2 is down. As you can see, the response time reflects this.

You don't need to guess what the response time means. Relays send an explicit indication of why they failed to extend a circuit, although the client code loses this information fairly soon after receiving it. See also #3520 and #2576.

comment:3 in reply to:  1 Changed 7 years ago by rransom

Replying to nickm:

The best/easiest fix for the worst part of this is probably just to reject EXTEND cells to private addresses. The rest of this (where you probe a router's TCP state or firewall cfg by asking it to extend different places) is probably no so easy, or *as* critical.

I've got a patch in branch bug6710_023 in my public repository that should go into 0.2.3.x after review.

Looks good.

We should consider a backport to 0.2.2.

This should be backported. 0.2.2.x is still in TBB, and TBB users can still turn their Tor clients into relays (and bridges).

comment:4 Changed 7 years ago by arma

A) I'm fine with this going into 0.2.3. Though you'll probably be decreasing the chances that future debians take this 0.2.3 update -- I think this would be fine as an 0.2.4 fix too. I think it is not a critical bug (we've known about it for years, and this fix isn't much of a fix) and thus doesn't need to go into 0.2.2.

B) I doubt this is a bug on 'all released versions of tor'. For example, before 0.0.8pre1 relays would only extend on connections that already had a tcp connection open.

comment:5 Changed 7 years ago by nickm

A: The bug is the private network thing.

B: Okay.

comment:6 Changed 7 years ago by nickm

Also it needs a specification.

comment:7 Changed 7 years ago by nickm

Fixed the spec in nickm/bug6710_spec. Updated the branch to have a more correct changes file.

comment:8 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.2.x-final

Roger agrees with merging this in 0.2.3. I'll mark as potentially backportable for 0.2.2 but wouldn't hold my breath.

comment:9 Changed 7 years ago by nickm

(Merged it into 0.2.3 and beyond)

comment:10 Changed 7 years ago by nickm

Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final
Resolution: fixed
Status: needs_reviewclosed

Not going to backport for 0.2.2; debian would scream so loud, and they would be right.

comment:11 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:12 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.