Created attachment 296217 [details] [diff] [review] fix See the linked URL. We just have to add 9100 to our port blacklist.
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.
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 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?
10 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.
I can't check this in for a while, it being the weekend
(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.
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.
I don't think this patch would break that... someone should test
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 18.104.22.168) 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.
Maybe that error page should offer a way to enable the port.
(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.
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 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.
Shouldn't this be resolved?
(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.
Taking off the blocker list based on comment 12
Resolving wontfix per comment 15
6 months ago