Last Comment Bug 411569 - Block port 9100 to prevent printing attacks
: Block port 9100 to prevent printing attacks
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://ha.ckers.org/blog/20080108/cro...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-09 14:13 PST by Robert O'Callahan (:roc) (email my personal email if necessary)
Modified: 2008-05-09 11:25 PDT (History)
10 users (show)
mtschrep: blocking1.9-
dveditz: blocking1.8.1.12-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (1.09 KB, patch)
2008-01-09 14:13 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
cbiesinger: review+
dveditz: superreview+
dveditz: approval1.8.1.12-
mbeltzner: approval1.9+
Details | Diff | Splinter Review

Description Robert O'Callahan (:roc) (email my personal email if necessary) 2008-01-09 14:13:30 PST
Created attachment 296217 [details] [diff] [review]
fix

See the linked URL. We just have to add 9100 to our port blacklist.
Comment 1 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-01-09 14:27:38 PST
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.
Comment 2 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-01-09 14:30:54 PST
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 Daniel Veditz [:dveditz] 2008-01-09 15:02:29 PST
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?
Comment 4 Daniel Veditz [:dveditz] 2008-01-11 10:19:35 PST
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.
Comment 5 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-01-11 10:26:42 PST
I can't check this in for a while, it being the weekend
Comment 6 Reed Loden [:reed] (use needinfo?) 2008-01-11 11:14:11 PST
(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.
Comment 7 Brandon Sterne (:bsterne) 2008-01-11 13:38:52 PST
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 Christian :Biesinger (don't email me, ping me on IRC) 2008-01-11 17:23:58 PST
I don't think this patch would break that... someone should test
Comment 9 Brandon Sterne (:bsterne) 2008-01-11 18:39:30 PST
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.
Comment 10 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-01-12 01:40:03 PST
Maybe that error page should offer a way to enable the port.
Comment 11 Brandon Sterne (:bsterne) 2008-01-14 11:17:05 PST
(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 Daniel Veditz [:dveditz] 2008-01-14 16:09:33 PST
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.
Comment 13 Daniel Veditz [:dveditz] 2008-01-14 16:11:00 PST
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.
Comment 14 Mike Schroepfer 2008-01-22 13:18:28 PST
Shouldn't this be resolved?
Comment 15 Samuel Sidler (old account; do not CC) 2008-01-23 16:19:02 PST
(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 Mike Schroepfer 2008-02-05 18:28:04 PST
Taking off the blocker list based on comment 12
Comment 17 Mike Schroepfer 2008-05-09 11:25:45 PDT
Resolving wontfix per comment 15

Note You need to log in before you can comment on or make changes to this bug.