Update banned-ports list to block new standard services

RESOLVED WONTFIX

Status

()

Core
Networking
RESOLVED WONTFIX
11 years ago
10 years ago

People

(Reporter: dveditz, Assigned: bsterne)

Tracking

Trunk
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
Our banned-ports list is old and may be missing more potentially dangerous standard services such as the recently reported :9100 printer problem (see bug 411569)

We need to investigate other standard assigned ports at http://www.iana.org/assignments/port-numbers and see if there are others we need to block in Firefox 3.
Flags: blocking1.9?

Comment 1

11 years ago
maybe a better approach is to have a white list and warn the user if they are using a port for a protocol that seams odd.

For example we could throw a dialog similar to the intermediary cert dialog when a protocol is used on a port that isn't white listed.
(Assignee)

Comment 2

11 years ago
I agree that white list is a better security model in general, and will require less management than a black list moving forward as new attacks are discovered.

Would such a warning dialog be presented only when a user is browsing directly to a resource over a non-white-listed port?  Or would the dialog also pop up when there are resources being requested over non-standard ports, but from within a page served over a standard port?

An example from the Cross Site Printing white paper:
<img src=”myprinter:9100/Printed_from_the_web”>

Comment 3

11 years ago
i would think that we would want this dialog to pop up if any network request happened that had a port not on the white list.  So, in your example, that img src tag would throw an alert to the user.
These "warnings" will be unintelligible to almost all users, therefore useless. A blacklist sucks less than that IMHO.

One option might be to use a whitelist for cross-domain loads and POSTs, but allow any port for same-domain requests. This is apparently a lot harder to implement but we could do it.

Comment 5

11 years ago
I wouldn't go so far as to say they are useless. Dialogs have protected (more or less) client software for years.  Recall that it is just one dialog protecting you from accepting my CACert. :-)

and now back to the point. We also could just do away with the dialogs and require the use to edit preferences if they really want to connect on a wacky port.   (http://www.mozilla.org/projects/netlib/PortBanning.html)
(In reply to comment #5)
> Dialogs have protected (more or less) client software for years.

More accurately, they have failed to protect users for years.

> Recall that it is just one dialog protecting you from accepting my CACert. :-)

That's unfortunate.

Please (re)read http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf.
(Assignee)

Comment 7

11 years ago
I could not find a publish date for that paper, but it looks like the bulk of the statistics were collected from 2004-2006.  I think that, while historically ignored, security dialogs are becoming increasingly paid-attention-to by users, who are becoming more aware of phishing and other web attacks.  IMO, security dialogs are still an important tool that we should continue to use.

I still agree with the idea of a port white list to ship with Firefox, which can then be edited via preferences and/or security dialogs.  The messaging we can use for the dialogs could be much like personal OS firewalls that (a) briefly describe the risk, and (b) give the user the option to Deny, Allow Once, or Always allow.

This type of approach would be more secure by default, and would be flexible enough to allow web applications using non-standard ports to still be utilized.

This bug was opened in response to an attack recently reported involving sending HTTP requests to network printers over TCP port 9001 via the browser.  Incidentally, this is the same port that Google Web Accelerator runs on, so we won't be able to simply blacklist that port without impacting GWA users:
http://webaccelerator.google.com/support.html#basics7

It is also a good idea for us to consider restricting requests made by external pages to resources in RFC-1918 space altogether.  I have yet to hear a legitimate use case for such requests to be allowed.  I would like to see these type of restrictions included in our overall strategy in this area.
(In reply to comment #7)
> I could not find a publish date for that paper, but it looks like the bulk of
> the statistics were collected from 2004-2006.  I think that, while
> historically ignored, security dialogs are becoming increasingly
> paid-attention-to by users, who are becoming more aware of phishing and other
> web attacks.  IMO, security dialogs are still an important tool that we
> should continue to use.

That paper is supported by very solid data from actual user studies. I don't want to just assume that things have changed in the last year. I want to see some evidence that supports your opinion.

Note that in the Miller phishing study ( http://portal.acm.org/citation.cfm?id=1124863 ), *MIT students* were *told* they were involved in a phishing-related study and the results were still appalling ... "awareness of phishing" didn't seem to help much there.

> I still agree with the idea of a port white list to ship with Firefox, which
> can then be edited via preferences and/or security dialogs.  The messaging we
> can use for the dialogs could be much like personal OS firewalls that (a)
> briefly describe the risk, and (b) give the user the option to Deny, Allow
> Once, or Always allow.

Those personal firewalls are useless for the reasons cited in Gutmann's report. Most users are incapable of answering the questions those dialogs ask. Most users, even those few who could understand the questions, simply learn to click on "Allow" to make them go away, due to the high false positive rate ... after the first 99 false alarms, your fingers know the next one is a false alarm too.

Now, the situation here is a bit better, because most users will rarely see a "bad port" security dialog/infobar. Of course, it's not clear that they'll even read enough of the text to distinguish it from the dialogs/infobars they do see regularly.

Comment 9

11 years ago
Moving to blocking list - we should resolve one way or another for FF3
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Flags: tracking1.9+ → blocking1.9+
Priority: P3 → P1
(Assignee)

Comment 10

10 years ago
I'm working on updating this list.  Will definitely have an updated list for fx3.

Comment 11

10 years ago
Brandon - we'll need this for B5 to make sure we get the right testing...
(Assignee)

Comment 12

10 years ago
Currently there are no additional services that we want to add to the port-blocking list.  The risk of downstream website breakage is too high to justify blocking ports/services that don't have known HTTP exploits.

Let's remove blocking for Fx3 and we will address port-blocking needs as they arise.

Additionally, we may want to WONTFIX in favor of bug 354493.
Version: unspecified → Trunk
Taking this off the blocking list based on Comment #12.  Bug 354493 is the long term solution, and we won't block the release for that one either.

Brandon, you wanna mark this as WONTFIX?
Flags: blocking1.9+ → blocking1.9-
Priority: P1 → --
(Assignee)

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.