Critical Tor flaw leaks users’ real IP address | Hacker News Reader

Critical Tor flaw leaks users’ real IP address

arstechnica.com

239 pointssds11186 comments

> TorMoil, as the flaw has been dubbed by its discoverer, is triggered when users click on links that begin with file:// rather than the more common https:// and http:// address prefixes. When the Tor browser for macOS and Linux is in the process of opening such an address, "the operating system may directly connect to the remote host, bypassing Tor Browser," according to a brief blog post published Tuesday by We Are Segment, the security firm that privately reported the bug to Tor developers.

Oh, well ... This is basically the same vulnerability exploited by the FBI's NIT. And this is the key aspect ...

> ... "the operating system may directly connect to the remote host, bypassing Tor Browser," ...

Well, in any sort of secure Tor implementation, such a thing should be impossible. The Tor client should be running in a router or gateway VM, and the machine used for browsing should not even have a public IP address. That's easy to manage with Whonix.

I've badgered Tor Project about this for years. And they've ignored me. Their mantra has been about keeping things simple, so more people will use Tor.

Damn.

Edit: They've plugged this leak, but the fundamental weakness remains. Tor Browser doesn't even block non-Tor connectivity with firewall rules. Even VPN clients block non-VPN connectivity.

I wonder how hard it would be to ship tor as a bundle with qemu and a very thin Linux image that provided just enough functionality to run it, then when you click on the start icon, it opens the emulator, which opens up the browser in a environment that's thin enough you don't even really need to pay attention to it because you've just got a window containing window containing your browser. With the right wm inside, you wouldn't even need that; it just happens that this browser window is actually running inside of the VM that shows up on your physical system.

I've been doing similar things, just in docker instead of a VM (and doing X11 forwarding via xpra). Not entirely happy with the setup yet; I still need to figure out how to do that with two containers so that the browser doesn't get accidental internet access. Not quite as good as a VM, but better than nothing and easier for me to maintain.

Why do you say "easier for me to maintain"? Are you talking about keeping them updated? That does get to be a pain.

Yep, keeping things updated. Right now I have it set to scrape the torproject web site to extract the location of the latest release, so that `make build` can get me an updated browser.

Check out tails: https://tails.boum.org/about/index.en.html

Pretty much that. Forward some X11?

Tails isn't a VM. It's a LiveCD.

That'd be cool. As long as the network isolation was solid. And easier than getting people to install VBox and Whonix.

shameless plug: https://github.com/r-a-w/TorProxy

This will ensure all outgoing traffic is headed for the Tor network. This would prevent this vuln from being effective as it would drop the outbound packets.

It might be irrational, but I have this vague notion that it's somehow less secure than Tor on a router. Breaking out of virtualization is certainly not easy, but it seems easier than hacking a locked down router.

I agree that a physically separate router (fully secured and patched itself!) forcing traffic through TOR is better still, but I see virtualization as a superior alternate to plain binaries with no extra layers, which is what's used today. It's also easier to use for the end user.

Yes, it's almost certainly less secure than running Tor on a router. But I sometimes use multiple Whonix instances, for different personas, and they hit Tor through different nested VPN chains. And using hardware for that would be too tedious.

You can always start two VMs with very thin OSs on them. The Tor proxy could even be a unikernel with no functionality beyond being a Tor proxy.

I've played some with that. Whonix uses a full Debian install for the gateway, and that uses lots of disk. I used OpenWRT VMs for a while, but Tor releases in their repo got way out of data, and I never managed a build.

If someone can point to a distro that works for this, many of us would be very happy.

I have some nice experiences running Alpine within VMs. Very small too, but I did so in order to test things for deployment in containers, not Tor services.

This sounds like the right approach.

Agree completely. If you are running a TOR service/browser you should at least have an option to block all data that wants to move outside of TOR. Imo, the option should be enabled by default. It is better to have a "broken" service rather than risk leaking the real IP.

If I recall correctly, wasn't silkroad and alphabay compromised by such a flaw? silkroad leaked the server IP through the captcha and I think something similar for alphabay.

If an adversary can achieve network access on your box, they can usually download malware.

At that point, it's game over. No firewall rules will protect you. The moment you shut off Tor, you're owned.

This is exactly why it's crucial to use Whonix or Tails.

Well, they can also download malware to when you're using Whonix or Tails. The Whonix workstation VM can not reach the Internet except through its Tor gateway VM. And the gateway VM only accepts connections from the workstation VM to the Tor process.

I'm not sure that Tails protects as well against malware. Its emphasis is on leaving no traces on your computer. Being a LiveCD, and wiping RAM during shutdown.

Does anyone know the differences between Whonix/Tails/Qubes? Which one is better?

Better regarding what? Depends on what you want. AFAIK, Whonix is focused on anonymity by using Tor as an integral part of its architecture. TAILS has the same goal but is designed specifically to be run from removable media and to leave no trace on the host system after it's done, much like using a live CD. Qubes is focused on security through isolation by means of an hypervisor. Whonix can run upon Qubes, beside others of course.

EDIT: if you want as foolproof of anonymity as possible it seems that Whonix holds an edge over TAILS and both are better than Qubes. Because Whonix routes all network requests through a locked down gateway VM, there is less chance that any program or system component can escape the Tor "funnel" than in TAILS and particularly Qubes, which focuses on security primarily.

I see, thank you. I want this to be running off a removable drive (although, realistically, I'll probably just keep using Tor Browser as I don't really do anything much with it), so I'll either use Tails or see if Whonix can run off a USB disk, thank you.

Whonix is a pair of Debian instances. One is a Tor gateway, and the other is a workstation. The Tor gateway isn't a router, in that it doesn't route packets. It just exposes Tor ports on a shared private network. The gateway and workstation instances can be run on separate hardware, as KVM or VBox VMs, or in Qubes.

Some years ago, I managed to build a LiveDVD with Debian OS, VBox, a pfSense Tor gateway VM, and a stripped-down Whonix workstation VM with Openbox. But it took ~20 min to boot :(

Yeah, Whonix on Qubes is the strongest option, I believe.

Just so you know, it is spelled "Tor" not "TOR".

It's a neologistical acronym. TOR makes more sense.

Maybe "TOR" makes more sense, but "Tor" is what Tor Project calls it. And according to Paul Syverson, it's not actually an acronym.

Yes, that was one of the ways that Silk Road got pwned. As I recall, it was an Apache error message that bypassed Tor.

Dream Market may have had a similar problem, but I don't know specifics. AlphaBay failed more simply. The founder allegedly used his real-name email address on the site. And sadly, after being arrested, he reportedly killed himself.

"Well, in any sort of secure Tor implementation, such a thing should be impossible. The Tor client should be running in a router or gateway VM, and the machine used for browsing should not even have a public IP address. That's easy to manage with Whonix."

I would go even further and suggest that a mission critical proxy should not live on a system configured with a real (routable) IP address.

As we can see in this instance, the OS is too "fussy" and the total implementation is too complex for even an expert in network security to be assured that they will not leak basic network IDs.

In my own use of tools like this, not only does the proxying software live on a system whose OS has never seen a real IP but I also throw a "slug" on the network border. "Slug" is the term I use to describe an invisible, layer 2 firewall[1] that blocks ALL network activity except for the addresses/ports of the remote proxy servers.

It's sort of like a condom for the network - no matter how weirdly your proxy software breaks, it could only ever talk to the VPN endpoint (and port) anyway ...

EDIT: To be clear, an example network design would be:

PC --> VPN_box --> slug --> modem

... and in this case, only the modem has a real IP, on the external interface. The VPN_box has non-routable addresses on both sides (and the slug has no IPs).

[1] Has no IPs assigned to it - is just an invisible ethernet bridge but is running IP filter rules.

I like that: "slug" :)

Me, I just have a perimeter router.

This looks like the latest in a whole suite of attacks using the same known, preventable channel. At a certain point playing whack-a-mole with the sources of side-channel leaks doesn't make sense anymore; just block those channels outright or admit you're not concerned about IP leakage.

This is nothing at all like the FBI exploit, which was an RCE vulnerability against firefox.

The reason they have been ignoring you about requiring a vm is likely because it is out of scope and doesn't make practical sense. They don't control the parent operating system.

This and FBI exploits both relied on apps bypassing Tor. Sure, FBI malware pwned Firefox, and dropped other malware that phoned home. But none of that would have mattered if Tor couldn't be bypassed so easily.

Isn't clear by now that reliable "anonymity" systems are impossible without control over the parent OS? Or at least, control over network access?

What do you mean the FBI's NIT used basically the same thing? Do you have a source?

What I mean is that it pwns users by bypassing Tor, and reporting their ISP-assigned IP addresses. I'm not arguing that the methods for doing that are similar.

[edited for coherence]

Whoa. Whonix has a Windows installer now?! NICE!

https://www.whonix.org/wiki/Windows

grugq released this 5 years ago... https://github.com/grugq/portal https://github.com/grugq/PORTALofPi

"Critical Tor flaw leaks users’ real IP address"

This is not a problem with Tor: this is a problem with the Tor Browser (and even then, only on macOS and Linux: users on Windows are not affected)... I'd recommend changing the title as this otherwise sounds like some extremely concerning flaw in the platform itself, which this attack is not targeting.

The Tor project itself muddles the distinction. If you go to their website and click "download", you get the Tor Browser. They actively encourage people to only use Tor Browser and not roll their own (because your browser requests would look different and you would be trackable).

The "only way" (without contortions) to get Tor without the bundle is via linux package manager.

I know a bunch of people who use Tor in various ways that does not in any way involve a browser at all, and the ramifications of an attack at these two levels (in the routing stack vs. in the app layer) are very different. I appreciate why Ars Technica's headline is what it is, but this is Hacker News.

Yeah, you're right. This would be one of the cases where it makes sense to change the title.

That's a good point, and the title ought to be "... Tor browser ...".

Still, for the vast majority of Tor users, Tor is Tor browser. However, most of them use Windows, and weren't affected. So maybe "... OSX/Linux Tor browser ...".

Ugh. Linux has this shiny feature called network namespaces. Tor Browser should run in a network namespace such that it has no access to the Internet and doesn't know it's real IP address in the first place and therefore can't have this kind of leak barring a code execution attack and a sandbox break.

Would that have even helped here? It seems like it's an OS process that's leaking the user's IP, not the Tor Browser.

What's the advantage over just using iptables?

    -A OUTPUT -m owner --uid-owner [Tor uid] -j ACCEPT
    -A OUTPUT -j DROP

So the browser itself doesn't know the IP. Then you don't have to worry about, say, a WebRTC bug leaking your IP. You also gain a considerable degree of protection from browser bugs in general.

Also, using network namespaces doesn't require root.

Using network namespaces does require root. User namespaces can give you something close enough to root to use network namespaces. But that only helps you if user namespaces are usable unprivileged, which they usually aren't, due to distro/sysadmin customization.

uid-owner hasn't worked properly for a long time. gid-owner does but oftenbreaks for apps such as KDE programs which hand-off to kioslaves for networking.

Network namespaces are much cleaner and can be created and destroyed without risk to other networking rules.

> uid-owner hasn't worked properly for a long time

Please say more. Cites would help too.

Just the other day I saw some file://-based exploit. Didn’t read the specifics of this, but not validating a URL’s scheme must be a very common source of problems. It’s so easy to overlook the scheme when everything is https?:// all the time. But alas, file://, it’s real, browsers attempt to work with it. Another edge to be aware of!!

Lots of online services are vulnerable to this kind of attack. I've seen numerous forms that do things like check security headers, scan your HTML, or do benchmarking. You're supposed to enter a site like:

* https://example.com/

But instead you can access local files via file:////etc/passwd

The remote site does not get the contents of your /etc/passwd if you do that, due to same origin policy. And you cannot see the /etc/passwd of the remote site. If you want to see your own, you can also open your /etc/passwd in vim. So, there is no vulnerability there.

The code I'm talking about typically calls `curl`, or similar, to download a remote URL, and show "stuff" about the contents.

I certainly don't expect to see my own file, but it is very common for remote sites to show THEIR /etc/passwd file, because they've used PHPs fopen function, or a curl-wrapper which didn't disable file:// URIs.

No. You can get the remote server's /etc/passwd in some cases. Most OS's would block a file that obvious from a non-privileged app but maybe /tmp/session.32eg3g3.txt is readable. There are sensitive local files that are readable by your web app so you must take precautions. This is in fact a common security hole caused by careless developers.

With a file:// URI? No you can't. That isn't how that works. You're confusing this with remote file disclosure attacks, which are totally different.

One risk mitigation for that is to sandbox the browser with something like firejail and whitelist access to only the profile directory and /tmp

This is the same exploit, it's from Friday.

If anyone is wondering how the attack works, here's a guess:

file://../../dev/tcp/74.125.225.19/80

That would also explain why it works on 'nix but not windows.

(This is probably mistaken, but the attack might be something along those lines.)

Hmm... Anyone have a link to the hotfix diff? We could just look rather than guess.

So...

    file://example.com/path/to/file

and/or

    file:////example.com/path/to/file

are valid file URIs which might cause an implementation to access the remote host example.com via smb/cifs, nfs or ncp protocols.

Source: https://tools.ietf.org/id/draft-kerwin-file-scheme-07.html

Ah yes, thank you. It really is that simple:

6.6. Applications/Protocols That Use This URI Scheme Name

Web browsers:

Firefox Note: Firefox has a unique interpretation of RFC 1738 (See: Bugzilla#107540), which affects UNC paths.

See Bugzilla#107540 from 16 years ago:

https://bugzilla.mozilla.org/show_bug.cgi?id=107540

---

If url format is file:////servername/dir/file.html Mozilla does not navigate to the link. This format works in IE5.

Reproducible: Always Steps to Reproduce: 1. Put url in page - format file:////servername/dir/file.html 2. Try to navigage to link 3.

Actual Results: Nothing

Expected Results: It should have opened link

---

reply from Neil Becker:

We have many links on our internal company website using the file:////server/a/b/c/ convention to access files on our network drives. mozilla seems to want file:///// (5 slashes) but IE and even the old netscape accept 4 slashes.

It seems that to access a local file, if you write file://D:/qtdocs/classes.html for instance, (2 slashes) mozilla automatically changes it to 3. so... when a link specifies FOUR slashes for a UNC name, it would make sense if mozilla would either expand it to FIVE slashes and check it like that, or accept the 4 slashes.

In our company's opinion, this is a bug, not a feature... It's a bug that'll cause us to not use mozilla and instead use IE or another browser than can do the file:////server/a/b/c links. it doesn't seem to be hard to fix - if there's four slashes in the link, change it to 5 and try it. just like you change 2 slashes into 3 for a local hard drive file. cmon!

I would really like to see this bugfix in the mozilla 1.0 release. this is NOT a duplicate bug (i checked the others that are claimed to be a dupe and its not). so would someone please fix this?????

thanks.

/dev/tcp doesn't exist on the filesystem, only in bash, and only if enabled; some distributions like Debian disable it.

Yeah, it was a wild guess. I just looked over all the new bug tracker entries in Tor since Oct 28th, but none of them seem particularly critical.

Our best bet would be to look at Firefox's commit history since the 28th.

One crafty way to determine the exploit would be to bindiff the hotfix'd firefox binary vs the previous release and examine the diffs in a disassembler to see what code changed. Non-deterministic builds make that tricky, but it's a neat technique to be aware of.

Isn't this pretty standard practice?

It is. But no one has posted details of the exploit yet. I was hoping someone would go find that out.

(I can't right now else I would.)

I can imagine why that would be useful, but that seems like a fundamentally misguided feature. The shell is a key partner in the Unix philosophy of small programs that do a particular thing. The maintainers of bash should have known better than to add this. What does /dev/tcp add to bash, other than security vulnerabilities, that couldn't be better accomplished with wget, curl, netcat, or similar programs external to bash?

If an attacker learned a Tor Browser user's real IP address yesterday, and the leak gets fixed today, can the attacker still somehow identify that user's traffic tomorrow?

Browser fingerprinting comes to mind, but is there another method?

Depends on the attacker -- if they're able to surveil the network upstream of the IP address they just learned, they could use timing analysis.

i.e. if the attacker is the FBI and they're trying to unmask visitors to an onion service, and they learned your IP address (and hence real life name) through this method, they can also confirm that you're visiting the site they're surveiling through correlating packet times leaving your interface and arriving at the surveiled server's.

Maybe there's a less dramatic way to do it too?

It's my understanding that this exploit wouldn't work with a hidden service because there is no way for your machine to know how to connect to it directly and the connection must be established through the Tor network, unlike a regular website. Is this not the case?

If they saw the person's username, then they can keep tracking that username. Same with any type of cookies. Https obviously makes it harder to do on sites they don't own, but it still works on http sites and https sites they own.

If you are paying very close attention you'll see that Tor hasn't been as reliable against well funded state actors for a while now. This is probably one of several vulnerabilities, and IP ownership at a given time is something readily accessible to most states if they really need it. It isn't going to go to catching petty criminals, but it could be used to catch a mole or a leaker.

> Tor hasn't been as reliable against well funded state actors for a while now.

Can anyone provide more detail? I never thought Tor was a panacea, but do we know that it's becoming more vulnerable?

I think most importantly, most people's IP address given by ISP is "fixed" for a long period of time.

Can someone please explain something to me? I’ve had this question for a long time, and finally decided to ask it...

Why does anyone rely on TOR for security? Obviously bugs happen, but it seems pretty easy to hack by any large organization....or government.

For instance, according to this page ( https://metrics.torproject.org/networksize.html ), there are less than 7,000 relays in the TOR network. To me, the US, British, Russian, or Chinese government could easily control most of those (i.e. running their own nodes) without anyone knowing, and use that to listen in (or at least infer) what TOR users are doing.

At that small of a scale, I’d bet a large corporation could even run a bunch of nodes.

How can that be protected against - or can it?

Am I missing something?

And this is why I usually run Tor as a transparent proxy, and put the browser in a VM. All traffic from the VM is forced through Tor via iptables.

One downside is that you no longer look like all the other users that are using TorBrowser. But I value non-identifiability (that they can't get to my real identity) more than non-trackability.

You could use whonix. That way you get a similar VM based setup and look like all the other whonix users.

This is truly such an obvious exploit, given well-acknowledged risks of opening files downloaded via Tor browser. I'm quite embarrassed that I didn't think of it. And I'm pretty sure that others have exploited it.

But on reflection, this is actually excellent news. At least, for those of us who don't rely on Tor browser. That is, Tor users occasionally get pwned. And now there's less reason to suspect unreported vulnerabilities in Tor itself.

With an implementation like Whonix, arguably the only safe and (relatively) easy way to use Tor, this exploit wouldn't have worked. The Tor Project's insistence on placing ease of use above security is admirable and understandable, but it provides a very false sense of security for the majority of users, to the point where it can potentially be detrimental.

We sometimes take for granted our intelligence in this domain and forget that the average Tor user doesn't know shit about opsec.

Just last week I found out a relative has been exploring Tor behind a VPN, and try as I may, I couldn't make them understand what a MitM attack was. They just read from a random page on the internet that it was safer to use a VPN and didn't bother doing research because frankly, how would they know what to look for?

Well, I recommend using Tor through VPN services. I worry more about ISPs doing MitM than VPNs. You have far more choice about VPNs than ISPs. Governments can pressure local ISPs far more easily than VPN services, which may do business from uncooperative jurisdictions.

And mostly, it's just that the VPN provides another level of IP obscurity. If an adversary compromises Tor somehow, and learns your VPN exit IP, there's at least a chance that they won't get your ISP-assigned IP. And if you use nested VPN chains, the adversary would need information from multiple VPN providers. It's the same logic behind three-relay Tor circuits.

Point taken, but your ISP cannot middleman a connection between you and a hidden service given a proper configuration. Likewise, a VPN provider cannot theoretically see your encrypted TOR traffic, but there are many caveats to this and a feeling of real security is only deserved if you pay attention to your opsec and browsing habits.

For the average, uninformed user, I rest easier at night recommending a direct connection to TOR. One less party to worry about. Security by obscurity is more of an afterthought and shouldn't be relied upon. The relative I mentioned was using a pretty shoddy VPN that I won't name here, but I definitely don't trust them.

Of course, with a network as diverse as Tor, one user's threat model will vary significantly from another's. For example one might be chiefly worried about deanonymization while another might be more concerned with timing attacks. For some of these use cases, having a VPN layer is pretty reasonable, but for others, potentially detrimental.

Most security advice is always dumbed down like that. "Always do this" "always do that" without actually explaining why or the risks of doing it etc.

There is a similar old attack with file URLs: Redirect-to-SMB (https://blog.cylance.com/redirect-to-smb). The fix is to block outbound SMB connections in your router.

Interesting that this has been posted 5 times in the past few days without receiving votes.

That's the randomness of what gets attention here. Many good stories fall through the cracks or need multiple submissions before they catch.

We try to mitigate this by looking through the stories that didn't get attention and re-upping the good ones (described at https://news.ycombinator.com/item?id=11662380 and links back from there) and/or inviting reposts.

How long has the exploit existed? Did it magically appear after Appelbaum was run out of town on vague allegations of sexual harrassment?

Please don't post flamewar comments to HN. We ban accounts that do this repeatedly (and have had to ask you this before), so would you please re-read https://news.ycombinator.com/newsguidelines.html and follow it from now on?

Let us quickly catch all the pedos on there and then close the leak for good.

Just this once...

Reply on news.ycombinator.com