> 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.
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.
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.
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.
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.
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.
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 :(
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.
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 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.
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.
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.
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.
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:
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.
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?????
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.