RE: Restrict loopback address to Secure Contexts?

Inline

From: Mike West [mailto:mkwst@google.com]
Sent: Tuesday, September 27, 2016 1:29 AM
To: Crispin Cowan <crispin@microsoft.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>; wilander@apple.com; public-webappsec@w3.org
Subject: Re: Restrict loopback address to Secure Contexts?

On Tue, Sep 27, 2016 at 9:43 AM, Crispin Cowan <crispin@microsoft.com<mailto:crispin@microsoft.com>> wrote:
I agree that an origin is not to be trusted if it comes via HTTP.

With that premise, I'd suggest that allowing HTTP arbitrary access to programs running on your local computer is a dangerous thing to do.
[Crispin] I did not say “arbitrary”, I specified post CORS preflight. Websites get to *request* access to loopback services, and those that wish to respond get to do so.

However, I disagree that this means that HTTP origins should not talk to loopback services.

I made some arguments against this conclusion in my last email. What do you think about them?
[Crispin] Your argument that I could find is that opt-in is meaningless in the presence of a network attacker. This is not true, for 2 reasons:

1.       The loopback service can do its own end-to-end authentication. AuthN and crypto are always possible over cleartext channels.

2.       The loopback service may be insensitive to MitM attacks because the scenario just DOES NOT CARE about network attackers. If the data provided is public anyway, and not interesting to corrupt, then who cares if a MitM messes with it?

A loopback service may well *choose* to talk to unauthenticated nobodies. I don’t see the case for blocking that.

Do you agree with the case for deprecating various "powerful" features over plaintext, and/or locking interesting new features to secure contexts? If so, how is this different?
[Crispin] I agree with blocking access to services that CANNOT defend themselves from HTTP sources. Location is an example, because it does not do any authenticating, has no authorization model, and leaks user personal information. I do NOT agree with blocking fun new features from HTTP just to use as a cudgel to force web sites to migrate to HTTPS.

-mike


From: Mike West [mailto:mkwst@google.com<mailto:mkwst@google.com>]
Sent: Tuesday, September 27, 2016 12:37 AM
To: Devdatta Akhawe <dev.akhawe@gmail.com<mailto:dev.akhawe@gmail.com>>
Cc: Crispin Cowan <crispin@microsoft.com<mailto:crispin@microsoft.com>>; wilander@apple.com<mailto:wilander@apple.com>; public-webappsec@w3.org<mailto:public-webappsec@w3.org>
Subject: Re: Restrict loopback address to Secure Contexts?

On Tue, Sep 27, 2016 at 6:37 AM, Devdatta Akhawe <dev.akhawe@gmail.com<mailto:dev.akhawe@gmail.com>> wrote:
My 2c: it is just plain weird to allow a seemingly powerful feature
like connecting to localhost from http sites (insecure contexts) but
block it from https sites (secure contexts). So, I am all for allowing
that.

I'm confused about what you're advocating here. :)

My suggestion is that talking to loopback should be treated as a powerful feature, and we should block non-secure contexts from doing so entirely, preflight or not. It's simply the case that in the presence of a network attacker, opt-in is meaningless, as the origin sent with the preflight isn't authenticated. That is, your coffee shop can inject a request to `http://127.0.0.1` that attacks locally-installed software. Even if that software tries to constrain itself to a subset of plaintext sites, the attack vector is both possible and exploitable so long as those origins don't tunnel over authenticated TLS.

Re blocking it from http sites:
@crispin Am I understanding right that you are saying "we should not
only allow https sites, but also http sites to connect to localhost"?
You do not have an objection to allowing https sites (secure context)
to connect to localhost though (currently blocked by mixed content)?

This is not blocked by Mixed Content any more. Based on conversations we had earlier in the year, we've aligned the definitions such that `http://127.0.0.1` should not be blocked from `https://example.test/`<https://example.test/%60>. That's shipping in Chrome, I believe.

Re the decision to block or not to block http->localhost: I believe
the spec that would most closely cover this is the "requirements for
powerful features" spec
(https://www.w3.org/TR/2014/WD-powerful-features-20141204/).

Nit: That's quite out of date. https://w3c.github.io/webappsec-secure-contexts/ is a more recent reference.

question then: is connecting to localhost a powerful feature? One
option is to argue that connecting directly is a powerful feature but
connecting when explicitly whitelisted isn't a powerful feature. Thus,
the end result would be: block access to localhost from insecure sites
right now and then allow it only via the CORS preflight opt-in.

I've argued the opposite above. In the same way that we no longer allow users to opt-in to sharing their geolocation data with plaintext websites, we should not allow locally installed software to opt-in to talking to the web in plaintext.

On 26 September 2016 at 14:03, Crispin Cowan <crispin@microsoft.com<mailto:crispin@microsoft.com>> wrote:
> On this, I would vote “no”. The purpose of the CORS preflight is to block
> random web pages from talking to loopback services that never expected to be
> talking to untrusted clients, we call these “naïve servers”. So if a service
> does not opt in by responding to CORS Preflight, then web pages don’t get to
> talk to it.

I agree that this should be a requirement, but I'd suggest that it's insufficient.

> If a service does opt in to talking to web pages, it is up to the service
> who they want to talk to, and how to authenticate them. There may well be a
> legitimate scenario to run a local web service that is secure and wants to
> offer service to any web page that asks. Made up example: suppose I invent a
> USB altimeter, and I want to offer altitude data to any web page. Just have
> your web page connect to http://loopback/:41717 (“altit” in l337 speak). So
> no, I don’t want to block non-secure pages from connecting to compliant CORS
> Preflighting services.

1. Sharing accurate altitude information with everyone on the web is a privacy risk (especially given the drift inherent in such measurements). I'd suggest not doing it. :)

2. If your altimeter is written like anti-virus software, it probably allows RCE via CSRF. Given the reality of IoT code quality, let's protect you from your local coffee shop.

-mike