7 ms·

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 #104

• gsnedders 6y ago
  > 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-think-of-it-its-999-likely-opera https://w3cmemes.tumblr.com/post/62942106027/if-you-can-thin... [1]: https://stackoverflow.com/questions/1836215/access-to-127-0-0-1-by-default-in-opera-10 https://stackoverflow.com/questions/1836215/access-to-127-0-... [2]: https://web.archive.org/web/20140302021701/http://my.opera.com/securitygroup/blog/2012/07/03/operas-cross-network-protection https://web.archive.org/web/20140302021701/http://my.opera.c...
  • gsnedders 6y ago
    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/ 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!)
    • loeg 6y ago
      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.
      • gsnedders 6y ago
        Still need to know where the top-level page is loaded from, though: you do want to allow requests from 127/8 to "localhost".
      • nucleardog 6y ago
        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.
• hanniabu 6y ago
  > 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?
  • anderspitman 6y ago
    You can look into tools like firejail to make this easier.
    • cameronperot 6y ago
      +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/ https://firejail.wordpress.com/ [2] https://firejail.wordpress.com/documentation-2/firefox-guide/ https://firejail.wordpress.com/documentation-2/firefox-guide...
      • anderspitman 6y ago
        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.
• AdmiralAsshat 6y ago
  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.
  • Thriptic 6y ago
    I always wondered what was going on when I saw localhost show up in the connections listing for a site in uMatrix, TIL.