Open
Bug 1335688
Opened 8 years ago
Updated 2 years ago
Cross-Site Printing (XSP) and CORS Spoofing
Categories
(Core :: Networking, defect, P3)
Tracking
()
NEW
People
(Reporter: jens.a.mueller, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: csectype-sop, sec-want, Whiteboard: [necko-active])
Attachments
(1 file)
984 bytes,
patch
|
mcmanus
:
review+
|
Details | Diff | Splinter Review |
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: http://hacking-printers.net/wiki/index.php/Cross-site_printing
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: http://hacking-printers.net/xsp/
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: http://hacking-printers.net/
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: https://developer.mozilla.org/en-US/docs/Mozilla/Mozilla_Port_Blocking
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.
Reporter | ||
Updated•8 years ago
|
Comment 1•8 years ago
|
||
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
Comment 2•8 years ago
|
||
Assigning it to Patrick. Hopefully we can tackle this together with bug 1299881
Assignee: nobody → mcmanus
Whiteboard: [necko-active]
Comment 3•8 years ago
|
||
: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
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
If we wanted to fix this sooner we could set network.security.ports.banned for our users with an extension or in a new release.
Attachment #8834431 -
Flags: review?(mcmanus)
See Also: → https://github.com/whatwg/fetch/issues/482
Updated•8 years ago
|
Comment 6•8 years ago
|
||
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:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Ttkgd4aPkW0/7Uwd-S16BwAJ
They want to add some port usage information to telemetry, maybe we should do that as well.
Comment 9•8 years ago
|
||
I've asked again in blink-dev.
![]() |
||
Comment 10•8 years ago
|
||
Comment 11•8 years ago
|
||
I wonder if Chrome is even still going to do this.
Comment 12•7 years ago
|
||
Bulk priority update: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Updated•7 years ago
|
Priority: P1 → P2
Comment 13•7 years ago
|
||
I am not actively keeping up-to-date on this, unassigning myself.
Assignee: evilpies → nobody
Status: ASSIGNED → NEW
Comment 14•7 years ago
|
||
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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•