Live data from Hacker News

Critical Tor flaw leaks users’ real IP address

arstechnica.com

41–50 of 91 posts

Re: Critical Tor flaw leaks users’ real IP address

#41
post #40
post #33

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.

What's the advantage over just using iptables? -A OUTPUT -m owner --uid-owner [Tor uid] -j ACCEPT -A OUTPUT -j DROP

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.

Re: Critical Tor flaw leaks users’ real IP address

#42

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!!

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

Re: Critical Tor flaw leaks users’ real IP address

#43
post #39
post #25

Earlier quoted context omitted.

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 domai…

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…

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.

Re: Critical Tor flaw leaks users’ real IP address

#44

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.

Re: Critical Tor flaw leaks users’ real IP address

#45
post #40

Earlier quoted context omitted.

What's the advantage over just using iptables? -A OUTPUT -m owner --uid-owner [Tor uid] -j ACCEPT -A OUTPUT -j DROP

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.

Re: Critical Tor flaw leaks users’ real IP address

#47
post #12

> 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…

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.

Re: Critical Tor flaw leaks users’ real IP address

#48

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

Re: Critical Tor flaw leaks users’ real IP address

#49
post #40
post #33

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.

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.

Re: Critical Tor flaw leaks users’ real IP address

#50

Earlier quoted context omitted.

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 somethi…

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.

Does anyone know the differences between Whonix/Tails/Qubes? Which one is better?
Post reply on HN