Closed
Bug 411569
Opened 17 years ago
Closed 16 years ago
Block port 9100 to prevent printing attacks
Categories
(Core :: Networking, defect, P1)
Core
Networking
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: roc, Unassigned)
References
()
Details
Attachments
(1 file)
1.09 KB,
patch
|
Biesinger
:
review+
dveditz
:
superreview+
dveditz
:
approval1.8.1.12-
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
See the linked URL. We just have to add 9100 to our port blacklist.
Attachment #296217 -
Flags: superreview?(dveditz)
Attachment #296217 -
Flags: review?(kampde)
Updated•17 years ago
|
Attachment #296217 -
Flags: review?(kampde) → review?(dcamp)
Updated•17 years ago
|
Summary: Block port 9100 to prevent cross-site printing attacks → Block port 9100 to prevent printing attacks
Updated•17 years ago
|
Flags: blocking1.8.1.12?
Reporter | ||
Updated•17 years ago
|
Attachment #296217 -
Flags: review?(dcamp) → review?(cbiesinger)
Updated•17 years ago
|
Flags: blocking1.9?
Hardware: PC → All
Reporter | ||
Comment 1•17 years ago
|
||
dcamp asked about CUPS. CUPS uses IPP which requires clients to HTTP POST a request with Content-Type: application/ipp, which hopefully Web content can't do.
Reporter | ||
Comment 2•17 years ago
|
||
BTW I don't have a network-attached printer so someone should really test this :-) (not that I expect a patch this simple to fail...)
Comment 3•17 years ago
|
||
Comment on attachment 296217 [details] [diff] [review] fix >+ 9100, // raw printer/direct IP printing > 0, // This MUST be zero so that we can populating the array sr=dveditz if you don't mind could you fix "we can populating" while you're there?
Attachment #296217 -
Flags: superreview?(dveditz) → superreview+
Updated•17 years ago
|
Flags: blocking1.8.1.12? → blocking1.8.1.12+
Reporter | ||
Updated•17 years ago
|
Whiteboard: [needs review]
Updated•17 years ago
|
Attachment #296217 -
Flags: review?(cbiesinger) → review+
Updated•17 years ago
|
Whiteboard: [needs review]
Updated•17 years ago
|
Attachment #296217 -
Flags: approval1.8.1.12?
Comment 4•17 years ago
|
||
Please land on trunk ASAP, would like nightly feedback as a sanity check that this isn't a commonly used HTTP port on a popular site.
Reporter | ||
Comment 5•17 years ago
|
||
I can't check this in for a while, it being the weekend
Keywords: checkin-needed
Comment 6•17 years ago
|
||
(In reply to comment #5) > I can't check this in for a while, it being the weekend It can't land anyway, as it isn't a blocker and the patch doesn't have approval. If it gets one of those, I'll land it.
Status: NEW → ASSIGNED
Keywords: checkin-needed
Updated•17 years ago
|
Attachment #296217 -
Flags: approval1.9?
Updated•17 years ago
|
Attachment #296217 -
Flags: approval1.9? → approval1.9+
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1
Updated•17 years ago
|
Keywords: checkin-needed
Comment 7•17 years ago
|
||
Before we land this, it is worth noting that Google Web Accelerator runs on port 9100 (localhost): http://webaccelerator.google.com/support.html#basics7 We may not want to block this before we consider the impact to those users.
Comment 8•17 years ago
|
||
I don't think this patch would break that... someone should test
Comment 9•17 years ago
|
||
The port restrictions do apply to services running on localhost. Viewing http://127.0.0.1:531 presents the error: This address is restricted This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection. The machines I tested on (Linux, WinXP both 2.0.0.11) don't have any services running on port 531, btw. I installed GWA on my Windows VM and noticed that selecting "Preferences..." opens http://127.0.0.1:9100/preferences I think that adding port 9001 would, in fact, break Google Web Accelerator.
Reporter | ||
Comment 10•17 years ago
|
||
Maybe that error page should offer a way to enable the port.
Updated•17 years ago
|
Keywords: checkin-needed
Comment 11•17 years ago
|
||
(In reply to comment #10) > Maybe that error page should offer a way to enable the port. Agreed. It would be optimal if we could present a dialog that would enable the user to unblock this, or any other black-listed port. It would also be nice if we could present the option to Allow Once or Allow Always, the way personal firewalls work.
Comment 12•17 years ago
|
||
Moving back to nominated blocking1.9 for reconsideration -- port blocking is probably a bad approach for this given other common services camped on that port. Blocking local (rfc 1918) would be a more productive approach.
Flags: blocking1.9?
Flags: blocking1.9+
Flags: blocking1.8.1.12-
Flags: blocking1.8.1.12+
Comment 13•17 years ago
|
||
Comment on attachment 296217 [details] [diff] [review] fix minusing for the branch. If this goes out in a trunk beta and doesn't cause a stir we might reconsider, but otherwise this seems like it could cause problems.
Attachment #296217 -
Flags: approval1.8.1.12? → approval1.8.1.12-
Reporter | ||
Updated•17 years ago
|
Assignee: roc → nobody
Status: ASSIGNED → NEW
Comment 14•17 years ago
|
||
Shouldn't this be resolved?
Comment 15•17 years ago
|
||
(In reply to comment #14) > Shouldn't this be resolved? I think we should probably resolve this bug as WONTFIX in favor of bug 354493. See also comment 12.
Comment 16•16 years ago
|
||
Taking off the blocker list based on comment 12
Flags: blocking1.9? → blocking1.9-
Comment 17•16 years ago
|
||
Resolving wontfix per comment 15
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•