Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Critical Tor flaw leaks users’ real IP address

arstechnica.com

Post reply on HN
Print view View original

61–70 of 91 posts

Re: Critical Tor flaw leaks users’ real IP address

#61

Post by sillysaurus3 »

phire wrote: post #48
sillysaurus3 wrote: post #16

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

Ah yes, thank you. It really is that simple:

6.6. Applications/Protocols That Use This URI Scheme Name

Web browsers:

Firefox Note: Firefox has a unique interpretation of RFC 1738 (See: Bugzilla#107540), which affects UNC paths.

See Bugzilla#107540 from 16 years ago:

https://bugzilla.mozilla.org/show_bug.cgi?id=107540

---

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

thanks.

Re: Critical Tor flaw leaks users’ real IP address

#62

Post by arbitrage »

3pt14159 wrote: post #56
anonymous5133 wrote: post #30

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…

Just so you know, it is spelled "Tor" not "TOR".

It's a neologistical acronym. TOR makes more sense.

Re: Critical Tor flaw leaks users’ real IP address

#63

Post by yjftsjthsd-h »

3pt14159 wrote: post #55
yjftsjthsd-h wrote: post #47

Earlier quoted context omitted.

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

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.

Re: Critical Tor flaw leaks users’ real IP address

#64

Post by busterarm »

mirimir wrote: 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…

grugq released this 5 years ago... https://github.com/grugq/portal https://github.com/grugq/PORTALofPi

Re: Critical Tor flaw leaks users’ real IP address

#65

Post by Ajedi32 »

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

Would that have even helped here? It seems like it's an OS process that's leaking the user's IP, not the Tor Browser.

Re: Critical Tor flaw leaks users’ real IP address

#66

Post by dxmalai »

arbitrage wrote: post #62
3pt14159 wrote: post #56

Earlier quoted context omitted.

Just so you know, it is spelled "Tor" not "TOR".

It's a neologistical acronym. TOR makes more sense.

it was something they are started to cheating and they give our IP address through catpcha.

Re: Critical Tor flaw leaks users’ real IP address

#67

Post by rbanffy »

3pt14159 wrote: post #55
yjftsjthsd-h wrote: post #47

Earlier quoted context omitted.

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

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.

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.

Re: Critical Tor flaw leaks users’ real IP address

#68

Post by Bartweiss »

mirimir wrote: 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…

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.

Re: Critical Tor flaw leaks users’ real IP address

#69

Post by mook »

yjftsjthsd-h wrote: post #47
mirimir wrote: 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,…

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.

Re: Critical Tor flaw leaks users’ real IP address

#70

Post by rsync »

mirimir wrote: 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…

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

Post reply on HN