
Critical Tor flaw leaks users’ real IP address - sds111
https://arstechnica.com/information-technology/2017/11/critical-tor-flaw-leaks-users-real-ip-address-update-now/
======
mirimir
> 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://](https://) and [http://](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.

~~~
yjftsjthsd-h
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.

~~~
3pt14159
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.

~~~
rbanffy
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.

~~~
mirimir
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.

~~~
rbanffy
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.

------
saurik
"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.

~~~
captainmuon
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.

~~~
saurik
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.

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

------
amluto
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.

~~~
mirimir
What's the advantage over just using iptables?

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

~~~
amluto
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.

~~~
catern
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.

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

~~~
stevekemp
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/](https://example.com/)

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

~~~
lawnchair_larry
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.

~~~
singlow
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.

~~~
lawnchair_larry
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.

------
sillysaurus3
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.

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

~~~
sillysaurus3
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.

~~~
qeternity
Isn't this pretty standard practice?

~~~
sillysaurus3
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.)

------
forapurpose
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?

~~~
cjbprime
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?

~~~
kakarot
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?

------
MR4D
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](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?

------
captainmuon
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.

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

------
mirimir
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.

~~~
kakarot
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?

~~~
mirimir
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.

~~~
kakarot
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.

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

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

~~~
dang
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](https://news.ycombinator.com/item?id=11662380)
and links back from there) and/or inviting reposts.

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

~~~
dang
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](https://news.ycombinator.com/newsguidelines.html)
and follow it from now on?

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

Just this once...

