Chrome team planning to block all access from browser to localhost wss

https://code.google.com/p/chromium/issues/detail?id=378566

by _urga • 11 years ago

74 83 11 years ago

code.google.com

_urga18• 11 years ago

This includes blocking access by web apps such as Dropbox to their local daemon, which currently rely on a public DNS record resolving to 127.0.0.1 and a secure localhost websocket server (using a certificate for the public DNS record's FQDN) to make the connection (with additional mutual authentication after the websocket handshake).

After this change, there will be no way for a web app to communicate directly with a locally installed daemon.

wingerlang• 11 years ago

As a normal user, i.e. someone who does't really keep up to speed with whatever is the latest news in cross-platform-XRGS-injection-attack, is this good or bad?

_urga18• 11 years ago

On the one hand, blocking access to plain http servers on localhost is a good idea as it prevents people from trying to probe router servers etc. which don't expect to be accessed from the web.

But on the other hand, blocking secure websocket servers on 127.0.0.1 using a public DNS record and valid SSL certificate, is going too far.

Secure websocket servers on localhost are often implemented precisely for the purpose of being accessed by the public web, and are secured for that purpose. It's very rare to find wss servers on localhost using a public dns record resolving to 127.0.0.1 and a valid ssl certificate (most people seem to think a wss server on localhost is not possible).

So this is bad for users. For example, it will break Dropbox's feature which allows you to open files from within the web app in a native application such as Excel (if you have the file synced on your computer).

If Chrome continue with this, then apps such as Dropbox will have to implement these kinds of features using server proxies. These will be slower and less secure since they will need to be able to guarantee that a TCP connection from a web browser and a TCP connection from a local daemon are from the same machine (this is not easy to do when NAT is involved).

nraynaud• 11 years ago

To complete with an example of that, easel, the hipster Computer Aided Manufacturing software is hosted in the web, and it assumes that your CNC router is on the local network to receive the instructions in a HTTP post request.

diminoten3• 11 years ago

After this change, there will be no way for a web app to communicate directly with a locally installed daemon.

Well, you could just not use Chrome.

_urga18• 11 years ago

Yes, but if you're developing a cross-browser web app you can't expect your users to just not use Chrome.

Piskvorrr5• 11 years ago

That's the same argument as "You could just not use IE4," and the same situation: "let's just break the web, we know best what's best for you." Ironic that it's Chrome this time, the browser that started out as the champion of NOT breaking the web.

justinschuh14• 11 years ago

I mentioned this above, but we plan to let the localhost/private page support an explicit opt-in, maybe via CORS headers. Those details may not be captured in the bugs yet because currently no one is actively working on this.

_urga18• 11 years ago

Websockets already have the Origin header as mentioned in the bug by Tyoshino: https://code.google.com/p/chromium/issues/detail?id=378566#c...

Edit:

From my other comments, there is the additional implicit opt-in shown by WSS itself on localhost requiring (1) a public DNS record and (2) a valid SSL certificate for that FQDN.

I doubt that there are WSS servers on localhost out there setup with a public DNS record and validating SSL certificate which are not also expecting public traffic.

Theodores• 11 years ago

Does this mean I cannot develop on localtest.me (that resolves to 127.0.0.1)?

dvirsky4• 11 years ago

From the description, it only means that external pages won't be able to access resources on localhost, but you could still develop on localhost as usual.

orf• 11 years ago

This is a good thing. I recently found an exploit in a widely-distributed bit of software that listened on localhost but had minimal protection against malicious inputs. Anyone who could trigger your browser to make a crafted request to locahost (which is very easy) could make this bit of software download and execute any remote executable.

_urga18• 11 years ago

Yes it is, but if you read closer, you will see that they are also planning to block access to secure websocket servers with public dns resolving to 127.0.0.1 and valid ssl certificates setup precisely for the purpose of being accessed by the public web. This is completely unnecessary.

acqq• 11 years ago

But then malware can exploit every user of Dropbox, for example, it doesn't even need their own certificate. And even the users wo don't have Dropbox are vulnerable throgh Dropbox's DNS entry.

logn2• 11 years ago

They're not blocking all access, just sub-resources from Internet pages (you can still develop/use local servers). And they're adding a command line switch and enterprise policy to allow localhost.

Also this is preferred way to communicate with localhost:

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

_urga18• 11 years ago

Sub-resources includes websocket connections. The link you point to is not a standard and will not work cross-browser. You will also need to package your app using Chrome's format AFAIK. Basically, it's not really an option at this point in time.

logn2• 11 years ago

I agree with you and someone has mentioned this on the issue, as well as a proposed exception to this policy: https://code.google.com/p/chromium/issues/detail?id=378566#c...

dvirsky4• 11 years ago

Yep, this is a good thing. Apart from dev work, I like the pattern of local Web UIs for installed apps, I wish they were more commonplace - without risking the user's security.

_urga18• 11 years ago

Yes, but it should not be blocking access to wss with DNS resolving to 127.0.0.1 and valid SSL certificate, which is what they are planning to do, breaking web apps such as Dropbox which rely on this.

graycat• 11 years ago

Sorry, but I didn't find "sub-resources" in my Webster's. Could we please have a definition or a link to a definition?

In general in documentation for computing, or other technical documentation, or any serious writing on any subject, we should avoid undefined terminology.

Sorry to be critical, but computer security is a serious subject; since all it takes is one little gap to have a terrible computer virus infection, we need to be quite clear right down to the level of each little issue, quite clear and explicit.

So far this year, I've spent over half my time fighting viruses. Bummer.

justinschuh14• 11 years ago

A subresource is basically additional content that a page includes via a URL (e.g. script, iframe, images). The problem underlying this is that any page on the web can currently probe and then attack devices and servers on your internal network or local host. So, the proposal is to block that by preventing remote websites from navigating to or including sub-resources from anything on your internal network or local host (unless some explicit opt-in or exception is configured).

justinschuh14• 11 years ago

We'd be blocking sub-resources and navigation from web to private. Of course, direct navigation via a bookmark or the omnibox would still work. And navigation or resource inclusion from private to the web would still work.

As I explained in another comment, we're also working on exception mechanisms (including per-page opt-in, possibly via CORS) to cover the valid use cases.

atomi• 11 years ago

Some of us still use tiddlywiki. Make sure that still works.

yskchu• 11 years ago

Well we can still enable it if we need it

"In conjunction with the change, we will need a command line switch and enterprise policy to revert to the older behavior for testing and legacy applications."

_urga18• 11 years ago

If you rely on connecting your web app with a locally installed daemon (properly secured using wss and additional mutual authentication) then that's not really an option either, as you can't expect your users to know how to use command line switches. Cutting off access to wss is a big deal.

andybak• 11 years ago

Command line switches are a bitch on OS X.

Is an about:config switch not being considered? If so I'd imagine the thinking might be "too easy to social engineer round this".

andor• 11 years ago

Not just to localhost, but to most of the IANA reserved space, including 192.168.0.0/16 and 10.0.0.0/8:

http://code.metager.de/source/xref/chromium/net/base/net_uti...

easytiger2• 11 years ago

How the hell do you access your router's admin page then?

_urga18• 11 years ago

That will still be possible. The issue is about blocking access to secure websocket on localhost from public web pages. Routers don't generally use websocket, and if they do, probably not secure websocket.

detaro• 11 years ago

By going there directly. It is only about sub-ressources in pages (so if you go to badsite.com it can't trigger a request to your router, which given the security track record of your average home router is a good thing)

wwarren• 11 years ago

Seems like it only limits OTHER sites/pages from being able to access localhost or 192.168.x.x I think you'll still be able to access those pages directly yourself

pilif2• 11 years ago

I can see to not allow connections to be made to any host in the local network. That's fine. But blocking access to the loopback interface is IMHO going a bit too far as this was until now a very portable and secure way for websites to talk to locally installed helper applications.

Dropbox does this, Github for Mac does this (and incidentally, my own home-grown solution for reading barcode scanners does this too).

I really don't want to have to end up in a world where we have to write browser-specific solutions (the method recommended in the issue is chrome-specific) for these kind of things.

silon3• 11 years ago

Unfortunately, 'localhost' is not multiuser safe. So a better (cross browser!) alternative would be OK.

icebraining• 11 years ago

Multiuser on localhost can be safe like any other website; you just need authentication.

justinschuh14• 11 years ago

I filed this bug (along with http://crbug.com/458362), and there's a bit of context that may be missed. First, this is to protect weak devices and services on private networks or localhost, that really can't be safely exposed to attacks pivoting from the web. It will block only sub-resource loads and navigation from the web to private networks. Navigating directly (via bookmarks or omnibox) or in the other direction (from private to web) is still fine. Essentially, this is applying similar rules to what's already in place for file URLs.

We also appreciate the concerns for legacy apps, local servers, etc. That's why we plan on supporting blocking UI overrides, opt-in by the page on localhost/private (maybe via CORS headers), and permanent exceptions via the command-line and enterprise policy. So, there might need to be some small tweaks, but all the use cases I've seen described in this thread should still work in a portable manner after these changes are made.

Also, to my knowledge no one is actively working on these changes yet. Hence why the details in the bugs are still a bit nebulous. Although that is likely to change pretty soon.

_urga18• 11 years ago

It's great to block access to http routers on localhost, which I think was the original point of the bug.

But it's essential that access to secure websocket on localhost not be blocked in the process (which appears to be the case is it stands).

That's the reason for posting here in the first place.

justinschuh14• 11 years ago

As I already stated, we plan on having an explicit opt-in for these cases. However, what you're describing is an implicit opt-in (external DNS pointing to localhost, etc.), which can be trivially abused by third-parties in exactly the kind of attacks we're trying to prevent.

pfraze• 11 years ago

That's why we plan on supporting blocking UI overrides

By that do you mean, an in-browser prompt to allow the connection?

justinschuh14• 11 years ago

Pretty much. It would probably be an interstitial on navigation (similar to how certificate errors are handled) and a page action for subresources (similar to the shield page action for mixed content).

justinschuh14• 11 years ago

FWIW, the title is beyond sensationalist, and outright wrong. The title on the link is "Block sub-resource loads from the web to private networks and localhost".

xg152• 11 years ago

I absolutely agree that an exception for legitimate use cases is necessary. (And that a proprietery Chrome API - which in addition is only available to approved extensions - is not an option) However, I don't see what security benefits TLS or DNS records would bring in this case and why they should be requirements for the exception.

If your goal is to protect local daemons from malicious web sites, then I don't see why the usual CORS restrictions aren't enough. Maybe they aren't (You could tighten them a bit, e.g. not allowing "Allow: *" responses, treating all requests as CORS non-simple or even only allowing WebSocket connections if you must), but forcing TLS or a DNS entry doesn't seem to increase the security: If I were an attacker, there is nothing that keeps me from trying wss://localhost or wss://www.dropboxlocalhost.com in addition to plain localhost. So what security benefit would that bring?

If you want to protect a legitimate web page from malicious daemons, those measures won't help you either: I can simply download your legitimate daemon, extract the TLS private key and generate a valid certificate for www.dropboxlocalhost.com myself - or I just install a custom root CA certificate and use my own private key. But I don't think defending against the latter scenario is very useful anyway: Either the "malicious" daemon has been purposefully installed by the user, in which case blocking it would be against user interests, or it is part of a malware. In that case, the malware will have dozens of other ways to compromise your web page and you will generally have bigger things to worry about.

So, why can't we simply use CORS to protect connections to localhost like we do for everything else?

_urga18• 11 years ago

The reason that web apps such as Dropbox currently go to all the effort of a public DNS record (www.dropboxlocalhost.com) resolving to 127.0.0.1 plus an SSL certificate for that domain, plus mutual authentication after the websocket is established, is because it's currently the only pragmatic way to setup a non-"mixed content" connection to a localhost websocket server. It doesn't increase security as you point out. It's just that it's the only way to do it.

Any other connection would be blocked by browsers (e.g. a connection from https web app to a non-tls ws localhost server). The bug ticket referred to would seek to block this last remaining way of connecting, forcing localhost daemons to connect to the web app via server proxy.

xg152• 11 years ago

Okay, that makes sense. But then the real problem is that solving what should be a trivial technical problem today requires an extremely wasteful workaround. If I understood jschuh correctly in [1] and [2], then they plan to make this workaround unnecessary by treating connections to localhost as secure even when over plain http/ws.

As I understood, connecting to a daemon, both over ws and wss will still be possible, as long as the - to be defined - opt-in headers are sent by the daemon. In fact, the associated change to mixed-content would even allow using plain ws://localhost on secure sites, which - as you told - isn't possible today.

Apparently vulnerable services exist and this is a security hole that needs to be closed. So legitimate users of local connections need to update their implementations anyway. If that's the case, I'd prefer a solution which just requires me to add a new response header and not need me to manage a new DNS entry and TLS cert for no real benefit.

I agree though that this change has possible sweeping implications and should be done as part of the usual HTML5 process and not unilaterally be chrome. Also, the opt-in protocol must be specified before this change comes into effect.

[1] https://news.ycombinator.com/item?id=9211034 [2] https://news.ycombinator.com/item?id=9210985

rasz_pl• 11 years ago

You want _your_ browser to connect to _your_ local resources?

BITCH PLEASE! Whats next? Maybe you want non gimped SD card access for you android apps? HAHA.

We have ze Cloud specifically so you are forced to use us as the middle man, and we can see all of your data. How else are we going to make any money off of you?

PS: Oh, and its about security in journa^^ of your data!

narrowrail• 11 years ago

The only people this would inhibit do not know what a daemon is in the first place. I have no interest in da clowd.

Chrome team planning to block all access from browser to localhost wss

Related Stories