[ekimekim]

That's because for decades binding to localhost has been taken to mean "only users on the local machine can access this". Now chrome is breaking that assumption through a leaky sandbox, and demanding everyone else change rather than fixing their own security issues.

[geofft]

Can you explain why this is a Chrome-specific issue? I believe that it applies to all web browsers, including Internet Explorer for UNIX (which I do have access to and I can test if you would like me to confirm). I remember this being a vulnerability class with CUPS, which listens on http://localhost:631/, about 10 years ago.

In particular, note that the request is not made to localhost, it's made to a DNS name that simply happens to resolve to 127.0.0.1. Should Chrome and also all other web browsers add a special case for DNS names that resolve to 127.0.0.1?

[gsnedders]

> I believe that it applies to all web browsers

It does not apply to late versions of Presto, where there was similar treatment of requests to various special-use addresses (after hostname resolution, if applicable) as to requests that result in TLS failures.

I believe, though it's been years since I dealt with this, that this caused various enterprise sites to stop working, many of which assumed they could access intranet hosts (which resolved to private IPs) from remotely hosted websites.

[eli]

In any event lacking this feature is not evidence of a "leaky sandbox" in Chrome.

[kodablah]

How about caching a DNS result for the duration of a tab? Doesn't solve everything but probably good enough. I don't think it'd break many things (sure it may affect some round robin DNS things for long-open pages that are Ajax'ing back home frequently, but that should be minimal)

[geofft]

I could believe that caching "is it localhost / RFC 1918 space or not" for a tab would have a sufficiently low false-positive and false-negative rate to be worth doing. It would still break the average business user who has an email half-written in OWA via an RFC-1918 address, puts their laptop to sleep, and goes home and expects OWA to still work over the public internet, but maybe OWA can figure out a solution there like local storage + document.reload(). It won't solve all the problems but it'll solve many of them.

I think caching all DNS resolutions is going to make a lot of cloud-native websites very sad (e.g., I'd imagine something like Slack would break quickly), and also cause poor performance because you don't get the benefit of a CDN's DNS server telling you that other servers are closer now. A lot of people have long-running tabs.

[kodablah]

I don't mind breaking legitimate uses rebinding here. I'm not familiar w/ how OWA changes IPs from private-network to public-network, but I'd say using DNS is the wrong approach. And Chrome can probably detect DNS server change and then evict its known cache anyways. Yeah, a first step is probably just localhost/private-IP specific.

[geofft]

It's just that OWA is a web app that is often configured to be accessible on the internal network via an internal IP, and on the external network via an external IP (so you can get webmail even if you're not in the office), but it's the same app.

I certainly don't think it's worth supporting this from first principles - i.e., had the web been designed the way you suggest from day one, that would have been great - but it's got a very large deployment, and "Chrome silently loses your Outlook emails because of a security issue in video games and a BitTorrent client" is a good way to get Chrome removed from enterprises, and other browsers to decide not to ship the same fix....

[tinus_hn]

Gmail is not minimal.

There is no quick fix for this.

[bpicolo]

Hopefully not, that will make local development very hard. Maybe an opt-out for it though, heh

[Matheus28]

Maybe if the address in the URL bar doesn't resolve to a local address, block access to local addresses.

Might break some enterprise stuff, but better safe than sorry, put an opt out of this behind a flag.

[geofft]

But it does resolve to a local address. The point of rbndr is that it switches between resolving to a remote address and to a local address, which is an entirely legitimate thing - https://owa.example.com for most companies will do exactly this when you move between the corporate network and the public internet.

[Matheus28]

>But it does resolve to a local address.

Huh? The exploit allows remote website you visit ends up having access to stuff bound to localhost. If a localhost website has access to other localhost stuff, it isn't as much of a big deal.

>The point of rbndr is that it switches between resolving to a remote address and to a local address, which is an entirely legitimate thing - https://owa.example.com for most companies will do exactly this when you move between the corporate network and the public internet.

IMO it's worth blocking it, and only allowing that behind a flag or a custom whitelist that the user maintains. Enterprises can easily do that.

[blattimwind]

That's false. Any website was able to send requests to 127.0.0.1 since that new thing called always. DNS rebinding has been a known vector for 10+ years.