Private hostnames/IP addresses.

[Mike West]

Hello, net-dev!

I'd like to poke at teaching our mixed content checker about private addresses (http://w3c.github.io/webappsec/specs/mixedcontent/#private-url) in order to stop the web from screwing with my router via subresource fetches (https://crbug.com/378566).

We're currently doing mixed content checks in Blink, while the information that I'd like to play with is in Net (net::IsHostnameNonUnique/net::IsIPAddressReserved).

Any thoughts about the best way to join those two worlds? I can certainly pipe a call down into Blink via obscure clients and delegates and Web* classes if that's the right way to go, but before I start plumbing, I figured I'd ask the experts. :)

-mike

[William Chan (陈智昌)]

[ -wlllchan ]

Sorry, I'm confused by what the difficulty is. Does Blink not already have a build dependency on libnet? If it does, then can't you just call the functions you need?

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAKXHy%3DdwJ7DCVaKcF6BcGx81XB6uU8ELwsTxmXBoAynADy3bUQ%40mail.gmail.com.

[Ryan Sleevi]

On Jul 30, 2014 7:59 AM, "Mike West" <mk...@chromium.org> wrote:
>
> Hello, net-dev!
>
> I'd like to poke at teaching our mixed content checker about private addresses (http://w3c.github.io/webappsec/specs/mixedcontent/#private-url) in order to stop the web from screwing with my router via subresource fetches (https://crbug.com/378566).
>
> We're currently doing mixed content checks in Blink, while the information that I'd like to play with is in Net (net::IsHostnameNonUnique

Don't use this.

/net::IsIPAddressReserved

Use this.

[Matt Menke]

What about trying to connect to reserved IPs via host names ("localhost" being the obvious one).  Doesn't seem like this would cover that case, and I'm not sure the renderer ever gets IP information in that case, either.

--

You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvYzqCDxotFrLgxuivfstDXeEbMQjKfkwhF%2BcYF50mamSQ%40mail.gmail.com.

[Matt Menke]

[-wlllchan] again.

[Mike West]

Will: We can't talk directly to net from Blink, I believe (or, a quick
search for "net/" includes turned up nothing). But we could certainly
put a platform API in and pipe things down from the content layer.

Matt: Right. That's step three. Step one is to do the easy stuff that
should be trivial, because I know I have time for that. Step two is to
find time to design a solution to step three. :)

Ryan: Why only check IP addresses? Wouldn't it be desirable to block
internal names as well? Or have I misunderstood the purpose of those
two methods?

-mike
--
Mike West <mk...@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[Ryan Sleevi]

On Jul 30, 2014 9:50 AM, "Mike West" <mk...@google.com> wrote:
>
> Will: We can't talk directly to net from Blink, I believe (or, a quick
> search for "net/" includes turned up nothing). But we could certainly
> put a platform API in and pipe things down from the content layer.
>
> Matt: Right. That's step three. Step one is to do the easy stuff that
> should be trivial, because I know I have time for that. Step two is to
> find time to design a solution to step three. :)
>
> Ryan: Why only check IP addresses? Wouldn't it be desirable to block
> internal names as well? Or have I misunderstood the purpose of those
> two methods?
>

The IP check is exact.

The name check is not, its a rough guess, and shouldn't be in the *blocking* path for security decisions, especially as new gTLDs are spun up weekly (and even if they were all preloaded for the next two years, based on a supposed ICANN approval list, it'd still only be a heuristic)

[William Chan (陈智昌)]

On Wed, Jul 30, 2014 at 9:54 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Jul 30, 2014 9:50 AM, "Mike West" <mk...@google.com> wrote:
>
> Will: We can't talk directly to net from Blink, I believe (or, a quick
> search for "net/" includes turned up nothing). But we could certainly
> put a platform API in and pipe things down from the content layer.

Hm, what's the point of the platform API now that Blink only supports the content embedder? In any case, sure, a platform API would work too.

>
> Matt: Right. That's step three. Step one is to do the easy stuff that
> should be trivial, because I know I have time for that. Step two is to
> find time to design a solution to step three. :)
>
> Ryan: Why only check IP addresses? Wouldn't it be desirable to block
> internal names as well? Or have I misunderstood the purpose of those
> two methods?
>

The IP check is exact.

The name check is not, its a rough guess, and shouldn't be in the *blocking* path for security decisions, especially as new gTLDs are spun up weekly (and even if they were all preloaded for the next two years, based on a supposed ICANN approval list, it'd still only be a heuristic)

Hm, did we ever implement mDNS support? What about those local names too? 

[Chris Bentzel]

mDNS is in, but used only for device discovery rather than to discover
http services.

Rather than teach Blink about private addresses, would it make sense
to pipe down a "Cancel requests which result in internal network
address" down to the network stack and have it take care of it? This
would cover both IP literals as well as hostnames that resolve to
internal addresses.

Do we have an idea of what this would break? For example, Spotify
installs a web server on localhost which pages retrieved over the
internet can interact with
(http://cgbystrom.com/articles/deconstructing-spotifys-builtin-http-server/).
Compat/Security tradeoff might be worth it though.

> https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAA4WUYjAePhZYTLPagsV9MzT_SDi2JJfjrDipbGm79Q%3D1Q0mJA%40mail.gmail.com.

[Mike West]

On Thu, Jul 31, 2014 at 1:54 PM, Chris Bentzel <cben...@chromium.org> wrote:
> Rather than teach Blink about private addresses, would it make sense
> to pipe down a "Cancel requests which result in internal network
> address" down to the network stack and have it take care of it? This
> would cover both IP literals as well as hostnames that resolve to
> internal addresses.

Doing this check in the network stack is appealing: it has the
advantage of really knowing what IP address we're connecting to for a
resource rather than just looking at the domain name and guessing. We
could certainly pipe all that resolution down to Blink, but that seems
excessive.

What would Blink see if the request is cancelled? Right now, we have
moderately decent error messages for mixed content blocking; if we
introduce blocks for connections to private IPs, I'd like to be able
to have similar notification for developers.

> Do we have an idea of what this would break? For example, Spotify
> installs a web server on localhost which pages retrieved over the
> internet can interact with
> (http://cgbystrom.com/articles/deconstructing-spotifys-builtin-http-server/).

I know this approach will break some things that Pebble is doing (see
http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0099.html
for example). I imagine it will break Enterprise Use Cases(tm) as
well. The difficulty is that Pebble's/Spotify's use case is more or
less indistinguishable from someone poking at my router in unfortunate
ways. I'd like to prevent that if at all possible.

> Compat/Security tradeoff might be worth it though.

I believe it is, but it's something that we'll have to keep an eye on
and evaluate as we go.

-mike

[William Chan (陈智昌)]

On Jul 31, 2014 5:12 AM, "'Mike West' via net-dev" <net...@chromium.org> wrote:
>
> On Thu, Jul 31, 2014 at 1:54 PM, Chris Bentzel <cben...@chromium.org> wrote:
> > Rather than teach Blink about private addresses, would it make sense
> > to pipe down a "Cancel requests which result in internal network
> > address" down to the network stack and have it take care of it? This
> > would cover both IP literals as well as hostnames that resolve to
> > internal addresses.

It sounds like a pretty specific, weird API to add to the URLRequest interface (presumably via LoadFlags). Is mixed content blocking really supposed to be dependent on host resolution?

>
> Doing this check in the network stack is appealing: it has the
> advantage of really knowing what IP address we're connecting to for a
> resource rather than just looking at the domain name and guessing. We
> could certainly pipe all that resolution down to Blink, but that seems
> excessive.
>
> What would Blink see if the request is cancelled? Right now, we have
> moderately decent error messages for mixed content blocking; if we
> introduce blocks for connections to private IPs, I'd like to be able
> to have similar notification for developers.
>
> > Do we have an idea of what this would break? For example, Spotify
> > installs a web server on localhost which pages retrieved over the
> > internet can interact with
> > (http://cgbystrom.com/articles/deconstructing-spotifys-builtin-http-server/).
>
> I know this approach will break some things that Pebble is doing (see
> http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0099.html
> for example). I imagine it will break Enterprise Use Cases(tm) as
> well. The difficulty is that Pebble's/Spotify's use case is more or
> less indistinguishable from someone poking at my router in unfortunate
> ways. I'd like to prevent that if at all possible.
>
> > Compat/Security tradeoff might be worth it though.
>
> I believe it is, but it's something that we'll have to keep an eye on
> and evaluate as we go.
>
> -mike
>

> --
> You received this message because you are subscribed to the Google Groups "net-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
> To post to this group, send email to net...@chromium.org.

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAKXHy%3Ddyb60q%2BecYL%2BkqC0PXCXGXSONCyZYohpONuP7OKzO7jw%40mail.gmail.com.

[Matt Welsh]

Note that when using a proxy it's the proxy, not Chrome, which knows what the IP address is. Chrome just knows the name. In the case of Flywheel (code name for the Chrome compression proxy) we have to use various heuristics to tell Chrome not to proxy local hosts that won't resolve on a proxy but would resolve at the browser, e.g., URLs for a Mifi router and the like.

Point is that an IP only check won't cover cases where the user is using a proxy and trying to access local hosts that won't resolve at the proxy. It would be great to figure out a general solution to this.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAKXHy%3Ddyb60q%2BecYL%2BkqC0PXCXGXSONCyZYohpONuP7OKzO7jw%40mail.gmail.com.

[Mike West]

On Jul 31, 2014 4:10 PM, "William Chan (陈智昌)" <will...@chromium.org> wrote:

> It sounds like a pretty specific, weird API to add to the URLRequest interface (presumably via LoadFlags). Is mixed content blocking really supposed to be dependent on host resolution?

According to the really clever guy who wrote https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-fetch, yes.

-mike

[Chris Bentzel]

Yeah, I was thinking this would be part of LOAD_FLAGS.

Part of the decision should probably be about what the attack is that
we are trying to prevent. If it is trying to prevent the internet web
page from reading data from local network then we may be able to do
more of this in Blink side (for example, we could pass along the
redirect chain as well as DNS resolutions, and then it would cancel on
that). If it is trying to prevent communicating to local networks in
the first place (due to concerns about exploiting buffer overflows
etc. with requests) then we may want to do this in the net stack -
since right now URLRequest doesn't stall on DNS resolutions to see
whether to proceed.

I still have concerns about the general idea - like how it would apply
to an RTCPeerConnection to a peer on a local network initiated by a
public web page, or chrome.cast, or increasing amount of having a web
or native app control local smart devices. But I'll check the
webappsec archives about it and discussion should happen there
instead.

[Matt Menke]

If this is something we want to do, should we really trust the renderer process to make these decisions?

[William Chan (陈智昌)]

Depends on the threat model. Note that renderers already do mixed content blocking.

[Matt Menke]

I had been assuming, perhaps incorrectly, that once we switch to a RenderFrame-based model, that would be moved to the browser process as well.

[William Chan (陈智昌)]

Aha. Good point and I don't know.

Anyhow, I am concerned about the dependency on host resolution. As mdw@ and cbentzel@ have pointed out, there are some edge cases here that need to be thought through.

Mike, I think the best thing to do for now is to implement a quick first pass without the host resolution dependency as the "step one" you indicated earlier. Presumably this would be done in the Blink loader first too rather than muddying the URLRequest interface.

Just my two cents.

[Matt Welsh]

Another data point. A couple of months ago, I noticed that Baidu's mobile website was embedding JS code which was trying to talk to local ports on the client device (using 127.0.0.1 URLs, though, I believe). Turns out this is an attempt by the site to talk to the locally installed Baidu Android app, if it's installed of course. The URLs used suggested it was querying the app for things like the user's location... Which would of course bypass Chrome's UI to get consent from the user to share their location with the site. One could imagine much more nefarious uses for such a backchannel to local apps. I think this kind of thing should be disallowed but I guess not everyone agrees as it was decided not to close this hole.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAA4WUYgZ9W%3DeU8xWN__GgshFRy40AR8RoeW27yfZ5ZbSJb_jnw%40mail.gmail.com.

[Mike West]

On Thu, Jul 31, 2014 at 5:12 PM, William Chan (陈智昌)
<will...@chromium.org> wrote:
> Aha. Good point and I don't know.

I do expect mixed content and CSP to move to the browser process as
part of (or as a result of) the general OOP frames/plznavigate work.

> Anyhow, I am concerned about the dependency on host resolution. As mdw@ and
> cbentzel@ have pointed out, there are some edge cases here that need to be
> thought through.

I don't have good answers for host resolution. I think we'll need to
sit down and go through more edge cases before we can reasonably
decide how best to address them. Moreover, it's not clear that there's
appetite from other vendors for such a change; I think we'd want the
spec to go through last call before making that sort of change, as
that's the only time that folks show interest. Sometimes not even
then. :)

> Mike, I think the best thing to do for now is to implement a quick first
> pass without the host resolution dependency as the "step one" you indicated
> earlier. Presumably this would be done in the Blink loader first too rather
> than muddying the URLRequest interface.

https://codereview.chromium.org/417153004/ and
https://codereview.chromium.org/430193002/ are a naieve approach that
appears to work. I have no idea how to test it in Blink, however, as
all layout tests run on 127.0.0.1. :( I'll start a blink-dev thread
about that issue. Hopefully I'm missing something.

-mike

[Matt Menke]

For layout tests running on 127.0.0.1:  I thought the issue was just mixed local and web content.  If the entire page is local, is there a problem?

[Mike West]

That's the problem. If the entire page is on a reserved IP address, we
shouldn't block content on a reserved IP address. If the entire page
is on a public IP, we shouldn't.

If our layout tests all run on 127.0.0.1 (a reserved IP address), I
don't know how to test that public IP address can't load reserved IP
addresses. :)

-mike
--
Mike West <mk...@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[William Chan (陈智昌)]

WAT

[Adam Rice]

I'm not happy with this approach. I don't think we should be breaking things for users now with a pretense of security, with nothing but the vague promise of actual security improvements at some point in the future in exchange.

I don't think we need any more information about the downside of this change. It's going to break stuff for plenty of people. We need more information about the upside. What is the actual level of exploitation of this hole? What is the actual cost to our users of leaving this hole open?

I don't think "we broke your app and ruined your day because we know what's good for you better than you do" cuts it.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAA4WUYgZ9W%3DeU8xWN__GgshFRy40AR8RoeW27yfZ5ZbSJb_jnw%40mail.gmail.com.

[Chris Bentzel]

These are all valid points Adam.

I'm just wondering if we should move the discussion about whether this
is a good idea to the standards list, and focus on how it would be
implemented to net-dev.