Submitted via IRC for SoyCow1984
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.
On Friday, members of the Tor Project issued a temporary work-around that plugs that IP leak. Until the final fix is in place, updated versions of the browser may not behave properly when navigating to file:// addresses. They said both the Windows versions of Tor, Tails, and the sandboxed Tor browser that's in alpha testing aren't vulnerable.
Related Stories
0.3.2.x alpha releases of Tor support version 3 of the Tor Rendezvous Specification (onion services protocol):
We are hyped to present the next generation of onion services! We've been working on this project non-stop for the past 4 years and we officially launched it two weeks ago by publishing our first alpha releases.
The new addresses will be longer and harder to discover:
The Tor team has been working on the new onion technology for the past four years, which aims to increase the anonymity level for onion services. In the legacy onion system the network itself could be leveraged to learn about the onion addresses that were using it.
With the new onion system, the onion services are completely private. Only you, the owner of the onion, and those to whom you will disclose the address, will know about your onion service' address. Nobody outside of their tight private groups could discover certain onion addresses, unless one of the group members disclosed it to others.
Websites such as Facebook, ProPublica, and The New York Times will likely want their address to be known to the whole public, so this benefit will not apply to them.
The legacy addresses will continue to be supported for years, depending on how fast the community adopts the new addresses.
Yesterday: Critical Tor Flaw Leaks Users' Real IP Address
(Score: 3, Interesting) by looorg on Tuesday November 07 2017, @07:09PM (21 children)
So for how long as that feature existed? Forever (or well since the beginning of the product)? All your secret surf time not to secret after all ...
(Score: 2) by janrinok on Tuesday November 07 2017, @08:06PM (7 children)
I don't use file:/// very often, and I personally cannot see why I would want to use it under TOR. I'm not a heavy TOR user but all the links that I have accessed have been http or https.
However, I'm sure that someone who uses it far more often than I do will come up with several use cases that I haven't thought of.
(Score: 0) by Anonymous Coward on Tuesday November 07 2017, @08:51PM (2 children)
And there was a *HUGE* stink about it when it was implemented too, for exactly this concern. I am not sure if the mail archives survive that far back, but someone with strong google-fu should be able to provide the supporting links for this as-yet unsubstantiated statement of fact.
Most of Mozilla's problems have been self inflicted. If it doesn't show up under Firefox, it might be under Phoenix, Firebird, or Mozilla Browser Suite, although I am pretty sure the debate happened during the switch from gtk to xul when a lot of FF features were getting paired away and stupid insecure shit added.
(Score: 0) by Anonymous Coward on Tuesday November 07 2017, @11:55PM (1 child)
When what was implemented, support for file:// URIs? That was in Mozilla in in 2001 [mozilla.org], if not earlier. Phoenix, which eventually became Firefox, was first released in 2002.
(Score: 0) by Anonymous Coward on Wednesday November 08 2017, @08:26AM
file:// URL's were in Netscape back around 1996, probably before that.
(Score: 5, Funny) by All Your Lawn Are Belong To Us on Tuesday November 07 2017, @10:19PM
... But when you do use file:///, please make it file:///dosequis
Stay unexploited, my friends!
This sig for rent.
(Score: 2) by MichaelDavidCrawford on Tuesday November 07 2017, @10:26PM (2 children)
However web design works much better if you run a localhost web server:
127.0.0.1 jobs.velvet
127.0.0.1 warplife.velvet
Velvet is one of my favorite strippers.
Yes I Have No Bananas. [gofundme.com]
(Score: 2) by maxwell demon on Wednesday November 08 2017, @04:50AM (1 child)
Why everything on 127.0.0.1? Why not
127.0.0.2 jobs.velvet
127.0.0.3 warplife.velvet
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by MichaelDavidCrawford on Wednesday November 08 2017, @06:05AM
It never occurred to me.
Yes I Have No Bananas. [gofundme.com]
(Score: 3, Interesting) by edIII on Tuesday November 07 2017, @08:07PM (12 children)
You still need to click on it. It's not like the early information leaks that necessitated the creation of Tails. That and apparently the windows version and the Tails version aren't vulnerable.
I'm more worried about the information leaks that happen that don't require interactivity with the user.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 2) by lx on Tuesday November 07 2017, @09:21PM (7 children)
Do you hover over every link on a webpage to check the URL before you click it?
(Score: 5, Informative) by Anonymous Coward on Tuesday November 07 2017, @10:11PM (2 children)
That only works if you have Javascript disabled as Javascript can change a link during the click action. (If you're using Tor Javascript should be disabled but often isn't due to it being enabled by default because the people setting the defaults are stupid fucktards that have no business even being around a computer let alone setting defaults in an application supposedly designed to be secure. *cough* But I digress...)
Proof:
1. Go to Google with Javascript enabled in a clean browser profile. (Clean profile in case some Adblock rule has implemented something to block this bullshit.)
2. Search for something. Doesn't matter what. Preferably something where you know what the destination site should be. "SoylentNews" would be a good search term.
3. On the results page, hover over a non-ad link. It will look like the site you expect it to be. Search for SoylentNews, get the link to this site. Nothing unexpected so far...
4. Right-click the link, then close the context menu by clicking somewhere else. Now hover over the link again. Not where you expected to go, is it? That's malicious Javascript at work changing links as you click on them. Malicious Javascript served up directly from Google. Malicious Javascript with HEAVY obfuscation applied in order to try to hide exactly what they're doing. (View the source and try to read the Javascript. Ugly, isn't it?)
5. Find another link, this time click and hold the left mouse button on it and drag the link a short distance away from where it was, but don't drop it. Before releasing the left mouse button, tap the escape key to cancel the click action, then release the left mouse button. Now hover over the link you just used the left mouse button on. Same thing, the link has been hijacked by Google's malicious Javascript so that it takes you someplace you didn't expect to go.
I've had nothing less than some form of a complete brick-shitting WTF?! response from every person I've demonstrated this to. Every. Single. Person. I've demonstrated it to some very knowledgeable systems engineers and CSOs in the hopes that SOMEONE would have known about this. Nope. Everyone who's not a complete tin-hat paranoid (*waves to the crowd* HI EVERYONE!) thinks hovering over links is a safe way to tell exactly where the link will take you.
1984? Nope, sorry, we went to plaid blowing past that at ludicrous speed a little over a decade ago and nobody even bothered to wave at it as we went past it.
And people call me paranoid...
(Score: 2) by MichaelDavidCrawford on Tuesday November 07 2017, @10:29PM
I used it for a while but found that it didn't always work.
Having an appealing meta description and an identical first paragraph after the header, combined with these sketchy links, enables your site to get more SEO without having anything to do with link popularity.
When I first wrote about that, the javascript links were only a small sample. Most were the real link. I expect no one objected - you know like boiling a frog.
Yes I Have No Bananas. [gofundme.com]
(Score: 2) by urza9814 on Wednesday November 08 2017, @12:48AM
Agree with you about Javascript not always being disabled, but it's far worse than just rewriting links. If it rewrites the link to 'file:///...', you'd know *something* weird happened. Even if you didn't know exactly what or why, you'd notice.
But I wonder if this flaw would still exist if the link is opened directly through a Javascript call. It won't open a browser tab, it won't redirect the page, it'll just fire a request to 'file:///whatever' and discard the response...but meanwhile your IP potentially gets exposed without you knowing anything happened at all. And without you clicking any link.
This was IMO one of the great advantages of the old* Freenet network. No scripts to expose information and no servers to retrieve it. No active content was supported at all, and you didn't connect to a server you just retrieved static files from a distributed storage system.
* I say "old" Freenet because I stopped using back during the 0.5/0.6 network split which was nearly a decade ago now. Based on the idiocy of some of those devs I wouldn't be surprised if they "fixed" that at some point...
(Score: 2) by edIII on Tuesday November 07 2017, @11:15PM (3 children)
Actually, yes. Yes, I do. I'm always looking at the URL and my trust factor in URLs I can't recognize, or go to Akimai or the cloud, is fucking zero. Since I'm most likely surfing with Tails anyways, I might click it for the hell of it. Most of the time though, if I don't recognize your URL, I just don't visit it.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 2) by Runaway1956 on Wednesday November 08 2017, @03:44AM (2 children)
Always?
I have a habit of hovering over links. But, I don't *always* do so. I'm really engrossed in some search or puzzle, and my mind is entirely occupied with what I am doing. Especially if I'm on a "trusted" site. I stop doing the hovers, I stop "copy this link address" and pasting it into a new tab, then LOOKING before pressing "enter".
It's one thing to stay secure while leisurely browsing. It's another thing when trying to rush, or wading through something complicated.
Maybe that's what separates the pros from the amateurs?
Abortion is the number one killed of children in the United States.
(Score: 0) by Anonymous Coward on Wednesday November 08 2017, @04:55AM (1 child)
And which do you imagine you are, Runaway?
(Score: 2) by Runaway1956 on Wednesday November 08 2017, @02:48PM
The answer seems pretty obvious - sometimes I forget. What did YOU think?
Abortion is the number one killed of children in the United States.
(Score: 0) by Anonymous Coward on Tuesday November 07 2017, @11:58PM
It's not often I get to say I'm not vulnerable because I'm running Windows. <sarcasm>Unfortunately</sarcasm> I'm not running Windows right now.
(Score: 0) by Anonymous Coward on Wednesday November 08 2017, @03:03AM
Does it only happen if you click in A HREF or does it also happen with URLs in IMG SRC? What about iframes? The docs linked only mention URLs and clicking means loading data, but again, no specifics about other loading, like frames, videos or images.
(Score: 5, Insightful) by maxwell demon on Wednesday November 08 2017, @05:18AM (1 child)
There are plenty ways of loading extra data without anyone clicking. Look at the following example page:
You see, plenty of ways to contact a server without the user clicking a link. And that file doesn't even use JavaScript.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Thursday November 09 2017, @09:48AM
Except you can't generally use file:// from another schema, like http:// because, you know, it's terrible shit. Otherwise you'll just easily could vacuum files from user systems. Try it.
(Score: 3, Interesting) by All Your Lawn Are Belong To Us on Tuesday November 07 2017, @10:16PM
So I didn't RTFA... but anyone want to take odds that this was how the FBI busted Silk Road? (And yeah, I'm sorry if I'm talking out my ass because while I've read accounts I thought they were cagey about how they claimed to get the exploit which unmasked Ulbricht. Maybe I'm wrong though.)
This sig for rent.
(Score: 4, Interesting) by takyon on Tuesday November 07 2017, @11:10PM (1 child)
https://blog.torproject.org/tors-fall-harvest-next-generation-onion-services [torproject.org]
http://www.tomshardware.com/news/next-generation-tor-onion-services-private,35835.html [tomshardware.com]
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 0) by Anonymous Coward on Wednesday November 08 2017, @02:54AM
https://soylentnews.org/submit.pl?op=viewsub&subid=23213&title=Tor%27s+Next+Generation+of+Onion+Services [soylentnews.org]
(Score: 2) by drussell on Tuesday November 07 2017, @11:54PM (2 children)
Seriously, though...
Nobody ever thought to test all the protocols when you're designing an "anonymous" browser? Really??!
(Score: 2) by jmorris on Wednesday November 08 2017, @12:11AM
TOR is not intended to be secure, it is security theater. What TOR most resembles is a honeypot. The government is the only ones with the immunity to operate an exit node. And the incident with dailystormer demonstrated beyond doubt that the claims made about the inability of the TOR network to know what was passing through the various nodes was rubbish.
Drug rings, kiddie porn, human trafficking, terrorism, all of that operated for years, safe under the claim that it was impossible to distinguish traffic and in the interest of protecting a few hypothetical human rights activists somewhere in some shithole that, somehow, won't just arrest you for possessing TOR or generating TOR traffic (never understood that argument really) we simply HAD to allow the bad stuff, not only allow we should all support TOR by donating money, operating transit nodes, adding chaff by conducting routine non-illegal browsing with TOR, etc.
But as soon as Anglin was banished from the clear net TOR operators began circulating patches to allow their nodes to identify and squash that one onion destination. Meaning it has always been theoretically possible, they simply never implemented the feature and depended on "you just don't understand the math" to shout down any dissent so they could get on with trading kiddie porn and attracting dumb terrorists for the government to monitor. Scam.
(Score: 0) by Anonymous Coward on Wednesday November 08 2017, @06:06AM
If you find a bug because of testing you simply got lucky. The only way to get ALL the bugs is mathematical proof. But that tends to be very complex and expensive. And Firefox is a massive amount of code, probably not an optimal choice for security. Having said that I use the tor browser daily. It's simply the best hope out there. Much better than ISP logging everything or trusting some random VPN not to do the same.
(Score: 0) by Anonymous Coward on Wednesday November 08 2017, @08:32AM (1 child)
How the heck does the browser even try to connect to any server, when the URL specifies file:// rather than http:// or https://?
file:// is the one that loads files from the local hard drive, you are not supposed to use any network protocol to access the local hard drive.
Did someone decide to use some fancy Gnome or KDE browser with integration to the KIO / GVFS "make the network appear as files" magic, rather than a regular browser?
(Score: 0) by Anonymous Coward on Wednesday November 08 2017, @02:10PM
My thoughts were similar when I read the post. One would think that this field is protocol specific, in which case "file://" shouldn't actually have a bound protocol at all.
But perhaps not. Maybe Mozilla uses this field more generically. Which wouldn't surprise me. Around IE4, things started getting real hinky. IE4 pretty much implemented everything in the most busted way possible, and other browsers decided to emulate broken functionality to give an appearance of compatibility. Of course that was the wrong move. And what resulted was what Redmond wanted: A totally busted insecure web.
If this is a hole, it is a stupidly big one. But it isn't a surprising one.