undefined | Better HN

0 pointsgeofft8y ago0 comments

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?

0 comments

gsnedders8y ago

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

eli8y ago

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

kodablah8y ago

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)

geofftOP8y ago

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.

kodablah8y ago

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.

1 more reply

tinus_hn8y ago

Gmail is not minimal.

There is no quick fix for this.

bpicolo8y ago

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

Matheus288y ago

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.

geofftOP8y ago

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.

Matheus288y ago

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

j / k navigate · click thread line to collapse

0 comments

gsnedders8y ago

> I believe that it applies to all web browsers

eli8y ago

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

kodablah8y ago

geofftOP8y ago

kodablah8y ago

1 more reply

tinus_hn8y ago

Gmail is not minimal.

There is no quick fix for this.

bpicolo8y ago

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

Matheus288y ago

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.

geofftOP8y ago

Matheus288y ago

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

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.

j / k navigate · click thread line to collapse