Open Bug 1335688 Opened 6 years ago Updated 4 years ago

Cross-Site Printing (XSP) and CORS Spoofing


(Core :: Networking, defect, P3)

48 Branch




(Reporter: jens.a.mueller, Unassigned)


(Blocks 1 open bug, )


(Keywords: csectype-sop, sec-want, Whiteboard: [necko-active])


(1 file)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.3.0
Build ID: 20150923064158

Steps to reproduce:

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. A detailed description of this `CORS spoofing' technique can be found here:

Proof-of-concept code which uses WebRTC to obtain the victim's local IP address and quickly enumerate printers in the LAN can be found here:

Actual results:

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:

Expected results:

This is not a bug in Firefox, but based on the abuse of legimtimate web features and standards (XHR, CORS, WebRTC).

A solution/workaroud would be to to add port 9100 to the list of blocked ports:

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 websites it would break.
Keywords: sec-vector
OS: Unspecified → All
Hardware: Unspecified → All
Component: Untriaged → DOM: Security
Product: Firefox → Core
If the solution is to block port 9100, then the bug should live in Core/Networking.
I tend to agree, but we'd need to figure out how common port 9100 is  for legitimate HTTP-ish applications and if we would block something useful.
Component: DOM: Security → Networking
See Also: → 1299881
Assigning it to Patrick. Hopefully we can tackle this together with bug 1299881
Assignee: nobody → mcmanus
Whiteboard: [necko-active]
:evilpies pointed out there is bugzilla history attached to it, which I suppose this is interesting for the original reporter. That being said, we should re-evaluate the blocking and should *not* take the wontfix from previous bugs!
See Also: → 411569
Assignee: mcmanus → evilpies
Ever confirmed: true
If we wanted to fix this sooner we could set for our users with an extension or in a new release.
Attachment #8834431 - Flags: review?(mcmanus)
Comment on attachment 8834431 [details] [diff] [review]
Block port 9100 used for Cross-Site Printing.

Review of attachment 8834431 [details] [diff] [review]:

please track chrome's landing of this and coordinate.

The general external can't connect to internal approach has exhibited tons of breakage in the past; fwiw
Attachment #8834431 - Flags: review?(mcmanus) → review+
Chrome's Intent to Deprecate and Remove:!msg/blink-dev/Ttkgd4aPkW0/7Uwd-S16BwAJ

They want to add some port usage information to telemetry, maybe we should do that as well.
I wonder what Google is doing, can somebody ping them?
I've asked again in blink-dev.
I wonder if Chrome is even still going to do this.
Bulk priority update:
Priority: -- → P1
Priority: P1 → P2
I am not actively keeping up-to-date on this, unassigning myself.
Assignee: evilpies → nobody
Reducing priority given that Chrome never shipped this and it likely breaks sites per comment 10. We should block some other additional ports, but that's probably best tracked separately from 9100.
Priority: P2 → P3
Blocks: fetch
You need to log in before you can comment on or make changes to this bug.