Comment by segfaultbuserr | Hacker News Reader

Comment by segfaultbuserr | Hacker News Reader

It's why Tor Browser restricts access to localhost by default. This problem was already predicted and considered by Tor developers back in 2014, see ticket #10419 - Can requests to 127.0.0.1 be used to fingerprint the browser [0] and has been fixed since then. Scanning localhost is a dangerous way to fingerprint the user if there are local open ports.

If you are not using Tor Browser and want to fix the security hole without disabling WebSocket completely, running the web browser in a separate network namespace is a workaround - you get a loopback interface which is independent from the main namespace, and you create a NAT interface within the network namespace to allow outgoing traffic. It's also a possibility for a website to probe other machines, such as the setting page on your router. For better protection, you should block all the local addresses defined by RFC1918 via netfilter/iptables as well.

For developers who needs less restrictive blocking for debugging, you can run multiple Firefox processes in different profiles (firefox -P --new-instance), each running in a different network namespace - to make it easy, you can code everything in a shell script and create desktop icons for them. I normally use an ad-blocked and 3rd-party-cookies-blocked profile for web browsing, but a naked Firefox profile for development.

[0] https://trac.torproject.org/projects/tor/ticket/10419

> It's why Tor Browser restricts access to localhost by default. This problem was already predicted and considered by Tor developers back in 2014, see ticket #10419

Sorry to invoke the meme, but Opera did it first[0], in Opera 9.50 (2008). I don't have a good reference to hand, but [1] is a developer complaining about this. [Edit: [2] covers the feature in some detail.]

Opera also blocked access to private IP addresses (so there were three tiers: public IPs, private IPs, localhost; higher tiers could communicate with lower ones, so the block was only unidirectional).

IE10+/EdgeHTML-based-Edge (and I know there was some talk about blocking this in Chromium-based Edge) also blocks it, so that too is prior art to the Tor change.

[0]: https://w3cmemes.tumblr.com/post/62942106027/if-you-can-thin...

[1]: https://stackoverflow.com/questions/1836215/access-to-127-0-...

[2]: https://web.archive.org/web/20140302021701/http://my.opera.c...

To add more about why current browsers don't do this:

One is clearly that you need to communicate the requesting IP deep enough into the network stack to the point where you get the DNS response (if there is one), which means there's a fair bit of work to ensure this is done everywhere;

Another is it's known to break corporate websites (https://internal.bigcorp.com/ on a public IP expecting to be able to access private IPs on their intranet), and smaller browsers are reluctant to lose corporate users by changing long-standing behaviour;

Then there's the WebRTC question: if two users on the same local network start a WebRTC call, do we want all this traffic to go to via first point where the public IP is known? For the majority of users the answer is no. And as long as that's possible, there's a (very limited) means of local communication. (But if it's limited to only things that respond to the WebRTC handshake, we're already in a much better place!)

Outside of DNS, the other reasons are about local networks, not 127.0/8. There's no good reason to permit port-scanning 127.0/8.

Still need to know where the top-level page is loaded from, though: you do want to allow requests from 127/8 to "localhost".

So remove "port scanning" since the only difference between port scanning and "legitimate" connection attempts is rate.

Should websockets be able to connect to the local machine?

In some cases that could be useful (even if something the kinds of people visiting this site might be uncomfortable with). E.g., a local daemon that listens for a websocket connection and a public web page that's used for managing it.

I don't think it was implemented this way, but think something like Battlefield 3's matchmaking: the user visits the online service and finds a match to join, and when they want to join it passes the relevant information to the game via websocket.

I imagine stuff like this has been implemented in at least a couple cases that you'd break just wholesale blocking connections to 127/8.

It can ask user explicitly like it asks for microphone. It is not common for a website page to need access to the local network services as it is to record microphone or request location data. So it's browser fault IMO.

In Kazakhstan we have e-government website. This website allows users to use crypto-tokens to access government services (every citizen can get a digital certificate representing his identity).

This website used to run Java applet. This applet was signed and it could access restricted APIs to access USB device. So website talked to applet and applet talked to USB device to sign data.

After major web browsers disabled Java applets, they implemented another approach. Now user must install a software which runs a web server on 127.0.0.1. This webserver listens on a specific port and uses web socket to communicate.

So government website now uses JavaScript to connect to 127.0.0.1:12345 using websocket. And then it uses that connection to interact with USB device.

So an ability for external website to connect to 127.0.0.1 actually is essential for this use-case.

My guess is that there are plenty of other websites which use local web server to interact with locally installed software. I know at least one another such a website: Blizzard website. It runs web server in its game launcher and website can communicate with it.

PS also they have to install custom trusted certificate because browser requires wss from https and there's no easy way to get a legitimate certificate for that kind of use.

Since these use cases already require having software installed on your machine, it seems fine and safer to use a browser extension with native messaging for this:

https://developer.chrome.com/extensions/nativeMessaging

https://wiki.mozilla.org/WebExtensions/Native_Messaging

That bypasses the entire certificate question and lets the website know it's communicating with exactly this app and not something happening to listen on the port (and vice versa, too).

... Or, depending on what you're doing, just use a real desktop app, perhaps with an embedded browser.

Yep, that might work. But that would require significantly more work to support all browsers and platforms. Currently it's just a Java application and it works independently of OS or browser.

The app running on localhost using WSS is not why they want[ed?] you to install a custom CA certificate.

https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...

No, that's not true. They used different certificate to MITM connections.

> So government website now uses JavaScript to connect to 127.0.0.1:12345 using websocket.

It sounds like random other websites (Ebay, etc) would be able to interact with people's USB devices this way too. Maybe without people knowing?

Yes, if this is programmed badly (missing security or a security hole).

The browser connecting to the government website accesses two servers: the original one and the second local one you install yourself on your system. The local server runs natively and therefore can access the USB device. Like all servers it should be programmed such that misuse by hackers is prevented.

That's already a security hole.

The only thing missing is a rogue website abusing it.

There's no guarantee you will never connect to any rogue website that abuses this government mandated backdoor.

When JavaScript establishes websocket connection, it sends its origin URL (I don't remember exactly where, probably that's in Referer header). So local webserver can deny connections from unwanted websites.

There's no need to roll your own hardware integration for crypto tokens. Browsers have been able to do PKCS#11 client certificates from smart cards for a long time, in case WebAuthN / U2F are too modern for you.

In Chromium it might not be blocked just because of an oversight (or because there was no consensus), see my other comment (and its parent): https://news.ycombinator.com/item?id=23253264

UWP apps block requests to localhost too for the same reason

I feel like uMatrix covers this as well. I've sometimes found myself redirected to some shady Chinese site and seen blocked attempts to localhost or 127.0.0.1 show up in the dashboard.

I always wondered what was going on when I saw localhost show up in the connections listing for a site in uMatrix, TIL.

> If you are not using Tor Browser and want to fix the security hole without disabling WebSocket completely, running the web browser in a separate network namespace is a workaround - you get a loopback interface which is independent from the main namespace, and you create a NAT interface within the network namespace to allow outgoing traffic. It's also a possibility for a website to probe other machines, such as the setting page on your router. For better protection, you should block all the local addresses defined by RFC1918 via netfilter/iptables as well.

As someone less tech savvy but still concerned, are there any guides available on how to do this?

You can look into tools like firejail to make this easier.

+1 for firejail [1]. There's a guide on how to do this for firefox [2] (see the network setup section), but this can be used with other applications as well.

[1] https://firejail.wordpress.com/

[2] https://firejail.wordpress.com/documentation-2/firefox-guide...

Note that the further I went down the sandboxing rabbit-hole, the more questions it raised about whether it's more or actually less secure. The main problem is that in order to work, these tools often use a setuid binary, which actually has more permissions than most users. So in theory if a sandboxed app finds an exploit in the sandboxing program (like firejail) that you're running inside, you could actually be worse off than it breaking out of whatever program you're sandboxing in the first place.

I think in this case though where you're more concerned about the very real problem of websites accessing localhost, it probably outweighs the maybe of a firejail exploit.

It's also possible to run a web browser in a docker container which can be interacted with on the host OS. This avoids the permissions issues with solutions like firejail:

https://blog.jessfraz.com/post/docker-containers-on-the-desk...

`docker` implies access to the Docker daemon, which is not an improvement over the setuid binaries anderspitman found distasteful.

https://docs.docker.com/engine/security/security/#docker-dae...

Genuine question, would LXD be any better? I'm not an expert in containerization but I find it really interesting.

There are some blogs that talk about how to do this: https://blog.simos.info/how-to-easily-run-graphics-accelerat...

If it runs in the same Xwindows session no.

If your docker is in fact podman your rootless might be attainable.

Please don't suggest using Docker to sandbox a GUI app.

That's not a good idea. The attack surface of docker is enormous compared to firejail.

Interesting point, I hadn't made it that far down the rabbit hole. I agree that it's not a complete solution, and possible risks of exploiting the sandbox itself should be taken into account on a case-by-case basis.

> these tools often use a setuid binary, which actually has more permissions than most users.

These tools often drop privileges as soon as the program is executed, in firejail, there's also an option to disalble root entirely within a namespace.

Reply on news.ycombinator.com