New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 6 users

Issue metadata

Status: Assigned
Owner:
Buried. Ping if important.
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 687530: Security: Cross-Site Printing (XSP) and CORS Spoofing

Reported by john.101...@gmail.com, Feb 1 2017

Issue description

VULNERABILITY DETAILS
Using `cross-site printing' (= cross-protocol request to port 9100 of a network printer), it is possible to perform attacks against intranet printers using the web browser as carrier. This issue has already been demonstrated in 2007 by Aaron Weaver to send printer spam or even to update the firmware for specific models.

A new version of the attack has lately been published, which allows malicious websites to bypass the same-origin policy and access data on the device by making the printer respond with a valid HTTP header including `Access-Control-Allow-Origin: *' using PostScript echo commands. It works on alymost any laser printer. A detailed description of the `CORS spoofing' technique can be found here: http://hacking-printers.net/wiki/index.php/Cross-site_printing

VERSION
Chrome Version: generic (tested with Chrome 52)
Operating System: generic

REPRODUCTION CASE
Proof-of-concept code which uses WebRTC to obtain the victim's local IP address and quickly enumerate printers in the LAN and list files on them can be found here: http://hacking-printers.net/xsp/

XSP in combination with CORS spoofing allows a web attacker to capture printed documents, obtain passwords stored on the device etc. Various attacks are documented here: http://hacking-printers.net/

This is not a bug in Chrome, but based on the abuse of legimtimate web standards (XHR, CORS, WebRTC) and the feature of a service/protocol to echo arbitrary strings.

A solution/workaroud would be to to add port 9100 to the list of blocked ports:
https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc?view=markup

Or maybe even disallow internet based websites to access intranet addresses at all by denying all requests from external to internal resources (at least if they use the private address spaces defined in RFC1918)? I can't think any website it would break.
 

Comment 1 by xzhou@chromium.org, Feb 2 2017

Components: Internals>Sandbox>SiteIsolation
Labels: Security_Severity-Low Security_Impact-Stable OS-Chrome Pri-3

Comment 2 by creis@chromium.org, Feb 2 2017

Cc: jsc...@chromium.org

Comment 3 by elawrence@chromium.org, Feb 2 2017

The final suggestion is similar what Issue 378566 aims to address, but if you can induce the victim to emit an Access-Control-Allow-Origin header that proposal may not be effective.

Comment 4 by sheriffbot@chromium.org, Feb 3 2017

Project Member
Labels: -Pri-3 Pri-2

Comment 5 by xzhou@chromium.org, Feb 6 2017

Cc: mkwst@chromium.org

Comment 6 by mkwst@chromium.org, Feb 6 2017

Cc: -mkwst@chromium.org elawrence@chromium.org creis@chromium.org
Labels: OS-Android OS-Linux OS-Mac OS-Windows
Owner: mkwst@chromium.org
1. I think we can safely drop the view restrictions, given that this is all information already published publicly (though I wish I'd heard of it before! It's a neat trick!).

2. I would not be sad at all to block port 9100. We're already blocking LDP on port 515 (RFC1179), which seems like good precedent to follow. It looks like there's an "Internet Printing Protocol" on 631 as well. I wonder if that has similar vulnerabilities?

3. I agree with Eric that https://wicg.github.io/cors-rfc1918/ aims to be a more generic solution to the problem of connecting from the internet to the intranet, but I also agree that protocols which expose raw text as headers make that a weak defense. Something more specific seems reasonable, especially if it's as trivial as blocking the port.

---

Any objections to the notes above? If not, I'll go poke Anne about adding those ports to the bad port list in Fetch (https://fetch.spec.whatwg.org/#bad-port), and see about deprecating-and-removing via blink-dev@.

Comment 7 by jsc...@chromium.org, Feb 6 2017

Components: -Internals>Sandbox>SiteIsolation Blink>SecurityFeature
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -Security_Severity-Low -Security_Impact-Stable Type-Bug
I agree that we should add 9100 to the blocked port list. I'm also dropping the vulnerability flags, because this is a request for mitigative action against a well-known third-party problem, rather than a vulnerability in Chrome.

Comment 8 by elawrence@chromium.org, Feb 6 2017

Re #6: Mike, can you also ask about 6697? We recently blocked that one too.

https://bugs.chromium.org/p/chromium/issues/detail?id=676951

Comment 9 by rsgav...@chromium.org, Feb 6 2017

Status: Available (was: Unconfirmed)

Comment 10 by mkwst@chromium.org, Feb 23 2017

Sent out an intent to deprecate port 9100, and poked at the spec as well. Folks want an evaluation of risk, so I need to add use counters to see what this would effect.

Comment 11 by eroman@chromium.org, May 8 2017

Issue 719614 has been merged into this issue.

Comment 12 by est...@chromium.org, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt

Comment 13 by est...@chromium.org, Feb 18 2018

Labels: -Hotlist-EnamelAndFriendsFixIt

Comment 14 by benhenry@chromium.org, Aug 1

Status: Assigned (was: Available)

Sign in to add a comment