Intent to Deprecate and Remove: Support for HTTP over port 9100, 6697, and 631.

[Mike West]

bcc net-dev@, security-dev@

Primary eng (and PM) emails

mk...@chromium.org, pal...@chromium.org

Summary

I'd like to add ports 9100, 6697, and 631 to our "bad ports" list, as they represent protocols that fail to handle HTTP requests in a secure way. For example, `http://server:9100/` will, with some cleverness, expose all the print jobs on a networked printer.

Motivation

http://hacking-printers.net/wiki/index.php/Cross-site_printing describes the issues with port 9100 in some detail. In short: printers don't understand HTTP, and can be convinced to echo arbitrary text through creative abuse of the AppSocket protocol.

Similar issues exist for the Internet Printing Protocol over 631.

We already blocked 6697 in https://crbug.com/676951 without much public discussion. Sorry about that!

Compatibility And Interoperability Risk

We don't have numbers for these ports, but my expectation is that they won't be used in HTTP requests on legitimate sites, as they're reserved for non-HTTP protocols, meaning that endpoints expected to be on these ports don't speak HTTP.

I've started a conversation on Fetch at https://github.com/whatwg/fetch/issues/482, and I expect other vendors should be on board once they see it.

Alternative implementation suggestion for web developers

Developers can embed resources from HTTP servers, rather than from printers.

Usage information from UseCounter

None.

OWP launch tracking bug

https://crbug.com/687530 and https://crbug.com/676951.

Entry on the feature dashboard

I'm happy to create entries if it's helpful for folks writing blog posts, but I don't think it makes sense to list each port we block individually, nor does it really make sense to have an arbitrary grouping of ports. *shrug* How would y'all like me to structure this?

-mike

[PhistucK]

I imagine some developers randomly picking a port for their local environment, ending up using one of those ports, confused about why it does not work (or worse, why it stopped working).

As long as there is a non-cryptic error message in the console ("Blocked a request to an unsafe port (6697). Try using a different port." and perhaps even a "learn more" link if you want to be nice), I agree that no announcement should be made.

A single entry can be created for all of the standard unsafe ports Chrome blocks (and another one for all of the nonstandard ones, for transparency and red colors on the dashboard), though it is really not of high priority, in my opinion.

☆PhistucK

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

[Victor Costan]

On Tue, Feb 7, 2017 at 3:30 AM, PhistucK <phis...@gmail.com> wrote:

I imagine some developers randomly picking a port for their local environment, ending up using one of those ports, confused about why it does not work (or worse, why it stopped working).

As long as there is a non-cryptic error message in the console ("Blocked a request to an unsafe port (6697). Try using a different port." and perhaps even a "learn more" link if you want to be nice), I agree that no announcement should be made.

+1 on the error message request. I have used 9100 as an HTTP port in development. 

    Victor

[Mike West]

bcc security-dev to move this back to `blink-dev`.

On Tue, Feb 7, 2017 at 1:01 PM, Hanno Böck <ha...@hboeck.de> wrote:

On Tue, 7 Feb 2017 11:28:46 +0100
Mike West <mk...@chromium.org> wrote:

> I'd like to add ports 9100, 6697, and 631 to our "bad ports

> <https://fetch.spec.whatwg.org/#bad-port>" list, as they represent

> protocols that fail to handle HTTP requests in a secure way. For
> example, ` http://server:9100/` will, with some cleverness, expose
> all the print jobs on a networked printer.

631 is used by cups for the local webinterface.

Yup. It turns out that I completely misread https://googleprojectzero.blogspot.de/2015/06/owning-internet-printing-case-study-in.html. I'm happy to drop 631 from this intent, as it does indeed intend to speak HTTP (it was just doing a bad job at some point in time).

Thanks for the heads up, Hanno!

-mike

[Mike West]

On Tue, Feb 7, 2017 at 12:30 PM, PhistucK <phis...@gmail.com> wrote:

I imagine some developers randomly picking a port for their local environment, ending up using one of those ports, confused about why it does not work (or worse, why it stopped working).

We do currently render an error in the console for these, but it's not terribly descriptive. "net::ERR_UNSAFE_PORT" makes sense if you know what it means, but I suspect that we can improve it a bit.

 

As long as there is a non-cryptic error message in the console ("Blocked a request to an unsafe port (6697). Try using a different port." and perhaps even a "learn more" link if you want to be nice), I agree that no announcement should be made.

A single entry can be created for all of the standard unsafe ports Chrome blocks (and another one for all of the nonstandard ones, for transparency and red colors on the dashboard), though it is really not of high priority, in my opinion.

I _think_ these are the only ports we block that aren't already in the Fetch spec. Once we land a patch for https://github.com/whatwg/fetch/issues/482, I hope we'll be back on the standards track.

-mike

[Philip Jägenstedt]

Given that some ports are already blocked, the only interesting question is that of risk. Without any data or good guesses, I would worry that the web will surprise us, as it tends to. If it's not in a rush, then adding a use counter in M58 and removing in M59 is probably the least overall work that still gives us some information before stable. There's also the option of an on-demand crawl, which is more work but gives you answers fast.

An httparchive search for ":9100" is totally tainted by "z-index:9100" and it seems plausible that someone might use random port numbers or a range of ports as some kind of obfuscation, so static analysis doesn't seem worthwhile.

[fbr...@mozilla.com]

Folks at Mozilla are generally interested. We have a patch ready[1] and would like to coordinate the launch of this.
That being said, we would also be interested in metrics.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=411569

[Rick Byers]

LGTM to deprecate, but I agree that we should have hard data on the expected level of breakage before we agree to remove.  What form would such UMA data take?  A new "HTTP ports" histogram that gets an entry for each HTTP connection (either as an enum or maybe just integers)?  I'm thinking of scenarios like the HTTP/0.9 non-standards ports removal where we broke a small fraction of connections but caused a ton of user pain due to one particular poorly written application. 

Note that if there's real urgency here (eg. active exploitation), there's probably still time to get the UMA stats into M57 and make a provisional decision for M58 based on data from M57 beta.

[Chris Harrelson]

On Wed, Feb 8, 2017 at 6:22 AM, Rick Byers <rby...@chromium.org> wrote:

LGTM to deprecate, but I agree that we should have hard data on the expected level of breakage before we agree to remove.

+1

 

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

[Philip Jägenstedt]

Do you think that we should deprecate without knowing anything about the usage? Do we stand to gain anything from deprecating a release or two earlier than we otherwise would?

[Mike West]

I think the metrics team would be unhappy with me if I added a new counter with ~32k buckets, so measuring the port distribution directly might be difficult. CCing Ilya and Alexei, who probably have opinions.

I can add a counter for 9100 in particular, with a deprecation message targeting M59; that should be simple enough. I don't think we're in a huge rush: this is an issue that people other than me have apparently know about for years. :)

-mike

[Harald Alvestrand]

Adding a counter that splits on <1024 (system ports), <49152 (maybe-static ports) and >=49152 (certainly-dynamic ports) seems doable.

(the particular split point is documented in https://tools.ietf.org/html/rfc6335#section-6 - nice to have a reference; I thought the dividing line was 32768.)

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

[Ilya Sherman]

On Thu, Feb 9, 2017 at 3:37 AM, Harald Alvestrand <h...@google.com> wrote:

Adding a counter that splits on <1024 (system ports), <49152 (maybe-static ports) and >=49152 (certainly-dynamic ports) seems doable.

Indeed, it would be reasonable to split the space into a few regions.  However, I'm not sure how useful this would be -- at least for the current discussion, it wouldn't help identify how much the unsafe ports are used.

Adding 32k buckets is definitely not scalable enough.  My advice would be to add counters specifically just for the ports of interest, assuming the goal is simply to understand the frequency of usage of unsafe ports.  (It's probably a good idea for the same histogram to include a baseline comparison, which measures the usage of safe ports.)

[Rick Byers]

FWIW I'm OK with either strategy.  The usage seems likely to be low enough that a deprecation message is highly unlikely to be spammy.  If the usage is high and we decide not to remove, that's seems OK.  But if there's no rush and we want to follow the normal path of measuring first, then that's great too.

[Geoffrey Sneddon]

On Fri, Feb 10, 2017 at 8:40 PM, Ilya Sherman <ishe...@chromium.org> wrote:
> On Thu, Feb 9, 2017 at 3:37 AM, Harald Alvestrand <h...@google.com> wrote:
>>
>> Adding a counter that splits on <1024 (system ports), <49152 (maybe-static
>> ports) and >=49152 (certainly-dynamic ports) seems doable.
>
>
> Indeed, it would be reasonable to split the space into a few regions.
> However, I'm not sure how useful this would be -- at least for the current
> discussion, it wouldn't help identify how much the unsafe ports are used.
>
> Adding 32k buckets is definitely not scalable enough. My advice would be to
> add counters specifically just for the ports of interest, assuming the goal
> is simply to understand the frequency of usage of unsafe ports. (It's
> probably a good idea for the same histogram to include a baseline
> comparison, which measures the usage of safe ports.)

Could we not just split it into 64 buckets, each with 1024 ports in
them? We can then see where usage is over all ports, and if usage of a
bucket for an unsafe port in it is too high we can then add a counter
for that specific port?

/g

[Ilya Sherman]

On a technical level, yes, we could.  It's not clear to me what the value of this sort of lumpy data would be; but I am not deeply familiar with the sorts of decisions that consumers of this data might want to make.  So, my general advice would be to record metric(s) that are both actionable and reasonably cheap to implement.  What metrics are actionable depends on the details of the analysis that's desired.

[PhistucK]

Is there a metric for protocol-inappropriate responses on non default ports? I think that could be interesting (especially with port-buckets, but without them it is also a beginning of an investigation).

Say, http://foo:9203/ does not respond with HTTP/1 (code) (text), HTTP/1.1 (code) (text), or https://foo:9203/ does not respond with an SSL/TLS response and so on.

☆PhistucK

[Frederik Braun]

This thread has been rather quiet lately. Are you going ahead with this?
If so, when?
It was also suggested to collect metrics, did that happen?

On 08.02.2017 11:50, fbr...@mozilla.com wrote:
> Folks at Mozilla are generally interested. We have a patch ready[1] and
> would like to coordinate the launch of this.
> That being said, we would also be interested in metrics.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=411569
>
>
> On Wednesday, February 8, 2017 at 5:32:49 AM UTC+1, Philip Jägenstedt wrote:
>
> Given that some ports are already blocked, the only interesting
> question is that of risk. Without any data or good guesses, I would
> worry that the web will surprise us, as it tends to. If it's not in
> a rush, then adding a use counter in M58 and removing in M59 is
> probably the least overall work that still gives us some information
> before stable. There's also the option of an on-demand crawl

> <https://www.chromium.org/blink/platform-predictability/compat-tools>,

> <https://github.com/whatwg/fetch/issues/482>, I hope we'll be

> back on the standards track.
>
> -mike
>

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "blink-dev" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/Ttkgd4aPkW0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.

[brian....@robustperception.io]

Hi,

I'm one of the developers for the open-source Prometheus monitoring system at https://prometheus.io. Port 9100 is the default port for our machine monitoring agent, the node exporter, which is accessed via HTTP GET. While this is a service that it'd be unwise to expose to the public internet, blocking all browser access would be quite annoying for administrators and developers. There are currently estimated to be around 500-1000 companies from startups to Fortune 500s actively using this service in production, plus however many non-production and non-corporate users.

What would be the impact to our users if this block goes through?

Doing a search for [http://localhost:9100/ -proxy.pac] I see several other services that would be affected in a similar fashion: https://github.com/mobz/elasticsearch-head (Elasticsearch is very widely run, I'm not familiar with this project but it appears to be moderately popular), what looks to be an old port for Hadoop's Job Tracker, and some versions of Stackstorm (https://docs.stackstorm.com/authentication.html#testing).

Yours,

Brian