> 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 <a href="https://" rel="nofollow">https://</a> and <a href="http://" rel="nofollow">http://</a> 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.<p>Oh, well ... This is basically the same vulnerability exploited by the FBI's NIT. And this is the key aspect ...<p>> ... "the operating system may directly connect to the remote host, bypassing Tor Browser," ...<p>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.<p>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.<p>Damn.<p>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.
"Critical Tor flaw leaks users’ real IP address"<p>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.
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 <i>can't</i> have this kind of leak barring a code execution attack <i>and</i> a sandbox break.
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!!
If anyone is wondering how the attack works, here's a guess:<p>file://../../dev/tcp/74.125.225.19/80<p>That would also explain why it works on 'nix but not windows.<p>(This is probably mistaken, but the attack might be something along those lines.)<p>Hmm... Anyone have a link to the hotfix diff? We could just look rather than guess.
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?<p>Browser fingerprinting comes to mind, but is there another method?
Can someone please explain something to me? I’ve had this question for a long time, and finally decided to ask it...<p>Why does anyone rely on TOR for security? Obviously bugs happen, but it seems pretty easy to hack by any large organization....or government.<p>For instance, according to this page ( <a href="https://metrics.torproject.org/networksize.html" rel="nofollow">https://metrics.torproject.org/networksize.html</a> ), 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.<p>At that small of a scale, I’d bet a large corporation could even run a bunch of nodes.<p>How can that be protected against - or can it?<p>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.<p>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.<p>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.
There is a similar old attack with file URLs: Redirect-to-SMB (<a href="https://blog.cylance.com/redirect-to-smb" rel="nofollow">https://blog.cylance.com/redirect-to-smb</a>). The fix is to block outbound SMB connections in your router.