Opened 7 years ago

Last modified 18 months ago

#4806 needs_revision enhancement

Detect and warn when running IPv6-using client without IPv6 address privacy

Reported by: nickm Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ipv6, tor-client, nickm-patch, intro, privacy
Cc: ln5 Actual Points:
Parent ID: #17811 Points: medium
Reviewer: Sponsor:

Description

Lots of IPv6 implementations default to deriving the last 48 bits of the address from local host's ethernet MAC address. There's an optional, usually-off-by-default feature that randomizes addresses for outbound connections (see RFC 4941), but not all clients will know where it is, or know how to turn it on.

That's problematic for users on laptops or other mobile devices, since their MAC address provides a way to tell it's still them as they move around the network.

Perhaps when Tor is running as a client, we should detect whether the address(es) we're using on outbound connections match any MAC address, and warn if so. (Without root, we can't do more than warn and suggest a workaround.)

On Windows, it's part of the info we get from GetAdaptersAddresses(). On Linux and OSX this info *seems* to be available via getifaddrs(): we just need to check for AF_PACKET addresses on Linux and AF_LINK addresses on Mac. BSDs seem to do the same thing as OSX here.

Failing that, on Linux, we can learn the MAC address of a socket with ioctl(SIOCGIFHWADDR). On OSX, it looks like we might need to mess around with the IOKit framework and a chain of twisty little calls that start with IOServiceMatching and end no place good.

We'll need to suggest some action for the user to take. For a relay, no action is necessary. For a bridge, I'm not too sure. For a client, the OSX and FreeBSD fix appears to be "sysctl -w net.inet6.ip6.use_tempaddr=1 " ; On Linux, it's maybe "sysctl net.ip6.conf.if.use_tempaddr=2". On Windows, it's probably somthing fiddly.

Child Tickets

Attachments (4)

20120823_check_ipv6_tempaddr.patch (3.0 KB) - added by cypherpunks 6 years ago.
Enables IPv6 tempaddr checking
0001-Adds-support-for-checking-ipv6-tempaddr-usage.patch (4.7 KB) - added by cypherpunks 6 years ago.
0002-Removed-dirent.h-from-main.c.patch (564 bytes) - added by cypherpunks 6 years ago.
0003-Fixed-to-use-tor-framework-functions.patch (3.0 KB) - added by cypherpunks 6 years ago.

Download all attachments as: .zip

Change History (40)

comment:1 Changed 7 years ago by ln5

Cc: ln5 added
Keywords: ipv6 added

comment:2 Changed 6 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.4.x-final
Priority: normalmajor

Changed 6 years ago by cypherpunks

Enables IPv6 tempaddr checking

comment:3 Changed 6 years ago by rransom

Status: newneeds_revision

cmouse posted a patch to check for MAC-leaking interfaces on Linux on startup. It needs some (cosmetic and non-cosmetic) changes to fit into Tor's style (cmouse is working on those), and some further design:

  • The function should report what it learns in a return value, not just in log messages, but it's not clear what needs to be returned. I suggested a simple tri-state ((a) no MAC-leaking interfaces found, (b) MAC-leaking IPv6 interface found, (c) don't know); Sebastian pointed out that that's not enough information to help the user fix a per-interface problem (but I'm not sure that's relevant on Linux).
  • This function should be called more often than just once at startup. Is calling it whenever Tor detects that the computer's IP address changes often enough? Does Tor detect changes to a computer's set of IPv6 interface addresses?
  • Someone will want to silence the warnings.
  • Someone will have a horrible connection and change IP addresses often, and should not be spammed with warn-level messages if they don't have time to (or don't want to) fix their MAC leak.
  • Someone will use a MAC changer, and not want to be warned that their computer is leaking its current (one-session-only) MAC.

comment:4 Changed 6 years ago by cypherpunks

I have now posted new patch which addresses the following issue:

  • It now returns -1 on error, 0 on success or if it's not applicable test on this platform, or number of interfaces affected
  • It accepts integer parameter, which if set to non-zero, will turn on logging
  • Calling it more than once, or silencing the warning, has not been done.

Changed 6 years ago by cypherpunks

Changed 6 years ago by cypherpunks

comment:5 Changed 6 years ago by cypherpunks

Status: needs_revisionneeds_review

comment:6 Changed 6 years ago by cypherpunks

Status: needs_reviewneeds_revision

Should be okish now

comment:7 Changed 6 years ago by cypherpunks

Status: needs_revisionneeds_review

comment:8 Changed 6 years ago by nickm

Looks like this handles the Linux version okay.

I've squashed these and made the code style a little more like ours in branch "bug4806_linux" in my public repository.

Before merging, we need to think about:

  • whether to be more restrictive about what interfaces we check on. If all my VM interfaces have use_tempaddr disabled, that might not be a problem. If I haven't enabled IPv6 at all, it isn't a problem.
  • Backing off from read_file_to_string, or adding a new flag to that function to yield the whole file. Right now, on my linux machine at least, doing fstat() on those files in proc says that the size is 0, so the function only reads an empty string.

comment:9 Changed 6 years ago by nickm

Another thing to think about: Maybe this shouldn't warn about link-local addresses.

comment:10 Changed 6 years ago by nickm

Other ideas (not mine): perhaps we should recommend editing /etc/sysctl.conf rather than calling sysctl(8)

comment:11 Changed 6 years ago by cmouse

Perhaps the message should be just changed to more generic, like "see manual" or something?

The code only checks whether use_tempaddr is set to non-zero. It does not harm to set it to non-zero on interface which only has link-local address. It'll raise awareness on the issue.

Link-locals can be used to bypass security on same subnet if the owner is not careful...

comment:12 Changed 6 years ago by nickm

Keywords: tor-client added

comment:13 Changed 6 years ago by nickm

Component: Tor ClientTor

comment:14 Changed 6 years ago by nickm

Tweaked a bit as "bug4806_linux_rebased" in my public git repository.

I've tried playing with this a little, but so far the false positive rate is ridiculously high. It warns even though all my IPv6 addresses are link-local; it warns even though I'm not connecting to any IPv6 hosts. That may be a support problem. Comments?

comment:15 Changed 6 years ago by nickm

I did a little work last night on an alternate approach that could be better for 0.2.5. (It's missed the 0.2.4 release deadline). It's in branch "bug4806_gently_v2" in my public repository.

comment:16 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

After discussion with andrea, moving to 0.2.5. Doing this only on linux with a high false positive rate is not really better than not doing it at all .. and the revised patch is too late for the 0.2.4 merge window.

comment:17 Changed 5 years ago by nickm

Status: needs_reviewneeds_revision

comment:18 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final
Status: needs_revisionneeds_review

This isn't tested enough for 0.2.5 IMO, and the code seems likely to need rebasing given other changes to get_interface_address6().

comment:19 Changed 4 years ago by nickm

Keywords: 026-triaged added
Status: needs_reviewneeds_revision

comment:20 Changed 4 years ago by nickm

Keywords: 026-triaged-0 added; 026-triaged removed

comment:21 Changed 4 years ago by nickm

Keywords: nickm-patch added

comment:22 Changed 4 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final

comment:23 Changed 4 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:24 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

Move *most* 0.2.7-triaged-1-out needs_revision items into 0.2.???. Keep a few based on my sense of the sensible.

comment:25 Changed 3 years ago by teor

Severity: Normal

OS X 10.7 (2011) and later have sysctl net.inet6.ip6.use_tempaddr set to 1 by default.
(If a user has changed these, they know what they're doing. If an admin has, perhaps we still want to warn the user.)

Source: https://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-knowledge-base-ip-transport/enabling-ipv6-in-mac-os-x
(US DoD root certificate)

comment:26 Changed 3 years ago by teor

Parent ID: #17811

comment:27 Changed 3 years ago by nickm

Keywords: intro added

comment:28 Changed 3 years ago by nickm

Points: medium

comment:29 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:30 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:31 Changed 18 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:32 Changed 18 months ago by nickm

Keywords: 027-triaged-in added

comment:33 Changed 18 months ago by nickm

Keywords: 027-triaged-in removed

comment:34 Changed 18 months ago by nickm

Keywords: 027-triaged-1-out removed

comment:35 Changed 18 months ago by nickm

Keywords: 026-triaged-0 removed

comment:36 Changed 18 months ago by nickm

Keywords: privacy added
Note: See TracTickets for help on using tickets.