Closed Bug 85601 Opened 23 years ago Closed 5 years ago

User interface to allow connections to blocked ports

Categories

(Core :: Security, enhancement)

Product:
Core
Component:
Security
Type:
enhancement
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: lmb, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: review for 1.8a)

Attachments

(2 files)

the warning dialog (screenshot)
7.56 KB, image/png
Details
The port:host manager window. (screenshot)
9.96 KB, image/png
Details 
I agree that port 1080 should be blocked by default (and probably others are
too), but I _do_ want to access a webserver running on port 1080, and major
corporate intranets are not going to change port numbers just because Mozilla
doesn't want to access them ;-)

Please, add a configuration option to override this behaviour. "Block access to
potentially dangerous ports" - "No, Yes, Ask", defaulting to "No".It might even
be possible to edit what Mozilla considers dangerous?
dougt - socks wasn't blocked by ns4...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: "Access to the port number given has been disabled for security reasons" → Access to the port number given has been disabled for security reasons
Over to dougt.
Assignee: mstoltz → dougt
There is a prefs that allows you to do this:

network.security.ports.banned.override

Just add all the ports you want "freed" comma delimited


Adjusting summary. This should be fixed for moz1.
Status: NEW → ASSIGNED
Summary: Access to the port number given has been disabled for security reasons → User Preference to override default port blocking..
Target Milestone: --- → mozilla1.0
what is milestone "mozilla1.0" anyway?  Moving to future.
Target Milestone: mozilla1.0 → Future
Doug: I added user_pref("network.security.ports.banned.override", 1080); to
myprefs.js. I still get "Access to the port number given has been disabled for
security reasons.

BTW, mozilla1.0 is a proper target. Adding it to keywords as well as 4xp on
Bradley's comment.
Keywords: 4xp, mozilla1.0
Of course I meant "added to my prefs.js". A misspeling. Sorry.
>>("network.security.ports.banned.override", 1080); <<

Just wanted to say the fix worked fine for me in the 0.9.2 milestone, PC 
version, using this format in all.js:

pref("network.security.ports.banned.override", "1080");
is myprefs.js read in?  I though it was "user.js"
Doug. I already corrected myself. I meant my prefs.js file. Anyway it did not
work. I did not try the file you write about (user.js). 

But I tried \Mozilla.org\Mozilla\defaults\pref\all.js as advised by Bill Mason.
This works. This is weird: all other prefs.js settings override all.js. Is
something wong with this one?
I checked putting user_pref("network.security.ports.banned.override", "1080");
into user.js in my profile directory. No success. The only way of making this
setting work is putting it in the default all.js. The downside is that after
every Mozilla upgrade (for us testers at least once daily) the setting will be
overwritten.
that should NOT be the case.  cc-ing the new prefs owner.  Maybe we should file 
a seperate bug if he thinks this is a bug.  Samir, please enlighten us...
I filed bug 89097 on the all.js versus prefs.js and user.js problem.
Depends on: 89097
*** Bug 89585 has been marked as a duplicate of this bug. ***
*** Bug 95132 has been marked as a duplicate of this bug. ***
I'd just like to point out that while port 1080 is SOCKs, 3Ware
(http://www.3ware.com) has (unwisely) chosen to use the same port for their
Escalade RAID controller status daemon. 

Our company has the same problem with port 1080 blocked for this reason. It's a
huge PITA to start editing obscure files just to get access to a RAID
controller's status. 

We've just told people to forget Mozilla for system maintenance and go fire up
Netscape or IE. 

ben, can you come up with some kind of UI design for this feature?
Assignee: dougt → ben
Status: ASSIGNED → NEW
Work around bug in Mozilla's URI parsing by being:
(*) annoying (block occasionally-used ports)
( ) insecure (allow sending of unseen e-mail)
Depends on: 83401
Terrible thing. Why are you censoring certain ports, while people may be running
the potentially offensive services on arbitrary ports, and valid ones on the
"restricted" ones? Make it a pref available from Edit->Preferences(->Advanced)
or turn it off completely. This method is annoying and lame.
OS: Linux → All
Hardware: PC → All
Change the current "Access to this port..." requester, so it displays something
similar like when using HTTPS:
-------------------------------------------------------------------------
"Accessing port# (...) on the server (...) attempted.
This poses potential security risk for the remote server
(maliciously formed webpages may try to use your browser for attacking it)

Should I continue?

[X] Remember my choice and never display this dialog again.

[Proceed anyway] [Cancel] 
---------------------------------------------------------------------------

The checkbox would simply add the port to
"network.security.ports.banned.override" or some other pref,  Cancel would do
what "[OK]" does now (dismiss dialog, cancel connection), [Proceed Anyway] would
allow to access the port on the specified server for this session. I think this
solution would make everyone happy.
<foo> attempted to access port _DDDD_ - _defaultprotocol_ using (_actual_protocol_http_) on the server _silly_. If you know the server you are trying to connect then this may be ok.
In other cases, this poses potential security risk for the remote server
(maliciously formed webpages may try to use your browser for attacking it) and you may be charged with criminal negligence.

[ ] Remember my decision for this server and port

[Continue] [Stop]

Key points:
1. list origin if known and the default protocol and actual protocol
2. some warning which should freak out the end user.
3. only remember for a specific server/port pair.
4. default to not remembering.

reason for (3): An option to allow users to walk around the entire web as accomplices to malicious people is not something that should be exposed via the gui.
Agreed on that. Eventually add a "blocked ports manager" (will be necessary to
remove "unwanted unblocks" anyway) with "wildcard support"
in form:

NET/MASK:port,startport-endport [ALLOW|DENY|ASK]
*.domain.com:port,port,startport-endport [ALLOW|DENY|ASK]

so advanced users could set it to whatever they like, whole domains could be
included etc - but only by people who know what they are doing. (high difficulty
makes cases like "0/0:1-65536 ALLOW" rare enough that probability of
webpage-exploit actually exploiting this would be so small that creating them
would be pointless.)
The requester would add just add single "host:port" pairs upon hitting
*:1080 ASK rule :)
(note it's a new performance issue - one more check against the list with each
host we visit)

That looks quite a bit of work, so I think this could be set as some far future
target, and for now simple "allow this port till the end of this session" would
suffice in some near release and target for "fine" solution could be quite far.


BTW, if the user types th
can anyone do up some screenshots of what they think the UI should look like?  ben?
Keywords: helpwanted
Looks quite OK, though there's a little too much text for an
"average microsoft software user". Besides that, the sentence
"If you know the server you are trying to connect..." is a bit unfortunate.
If the attacker uses your browser to attack a server behind your firewall, it's
on
your LAN, so most probably you know it. Unfortunately I don't have any better
ideas for that.
What mpt said. Can't just unblock 1080? The closest thing to an exploit would be
a DDNS attack of some sort, but people could just as easily launch that at port
80 - we can't send valid socks stuff, which starts with binary info.
The manager. Looks ugly (I started learning XUL today :) but gives you general
idea on how I imagine it. Actually, I wouldn't cry if the IP match
functionality was dropped, then the check could be performed even before DNS
lookup.

Watch carefuly so the contents of the prefs could be changed by user only,
not by any javascript or such, or someone malicious would surely start adding
0/0:80 DENY ;)

Hmm, and if the values were kept in a separate file (or be
exportable/importable) that would give us a free "content control"
functionality, like for parents adding XXX sites "ban file", or managers
denying anything outside their company - or even info booths with localhost:80
ALLOW and all the rest of the world denied.

And about that 1080 port... That won't be much of concern until Mozilla gains
significant share of the browser market. Why not remove the unfortunate 1080
from the ban list, and file a bug "Add port 1080 to the blocked ports list"
that would "depend" on this one. When the access management is ready, adding
1080 to the "default" list won't be a problem (since everyone will be able to
remove it easily) and until then people won't be discouraged to use Mozilla.

(ah, my previous unfinished "BTW". BTW, if user types the URL with the port in
the location window, by hand, you could be pretty sure it's not some
exploit...)
that sounds good to me.

I think we should probably try to make it easier for users to scan for the 
variable information (if your mockups were designed in xul then it should be 
easy for you to make these changes, hopefully we won't argue for more than 3 
drafts, but I can't guarantee that):

Warning attempting to access a reserved port. If you know the server you are 
trying to contact runs an HTTP server on the SOCKS port then this may be ok. In 
other cases, this poses potential security risk for the remote server 
(maliciously formed webpages may try to use your browser for attacking it) and 
you may be charged with criminal negligence. 

origin page: http://www.evil.org/wormscripts.html
target server: www.victim.org on port 1080 (SOCKS) using HTTP (POST)

[ ] Remember my decision for this server and port 

[Continue] [Stop]

--
Yes I know there's too much text. Someone else can work on trimming it, but 
they should probably talk to whichever lawyers mozilla.org/netscape/other-
vendors designate to handle disclaimer of liability :)
Assignee: ben → bw
Summary: User Preference to override default port blocking.. → User interface to allow connections to blocked ports
Yep, we will keep arguing - Moving the "valid data" outside the main block of
text is a good idea, but the unfortunate "If you know..." remains.

helpwanted remains in order: Any lawyers out there?

What about [Proceed anyway] [Stop immediately] ? That would freak most of lusers
and make them think and read some, before they click "continue" thoughlessly.
"Attempting to access to access server SERVER.HOST.NET on port PORT, which
usually does not belong to the requested protocol. This might mean that a
malicious webpage tries to use your browser to perform an attack on that server.
Are you certain that this attempt is a legitimate one?

[_] Never ask again for this server and port.

             [Proceed anyway] [ABORT]"




> (maliciously formed webpages may try to use your browser for attacking it)
> and you may be charged with criminal negligence. 

Hey, there're other countries on this planet, besides United States. =^.^=
Let's not put in any statements that don't work worldwide...
Keywords: mozilla1.1
Re: comment 11. As of 1.0RC3, in my testing, it appears that adding 

user_pref("network.security.ports.banned.override", "1080");

to user.js in the profile directory successfully unblocks the port. 
The message is subject for a strong discussion, in fact it's the main subject of
the "helpwanted", so all suggestions are appreciated.
So far we've agreed that plain unblocking a port permanently is not the way to
go, so neverthless we should work on some extension in the system (like
unblocking host:port pairs), not just adding the GUI to the existing pref.

btw, how comes I'm the owner of this bug? I'm not protesting, but I just wonder.
Besides, I could work some on the xul gui, but don't ask me to hook it up to the
existing code. I looked at it a bit and I admit that's far beyond my skills. 
*** Bug 149739 has been marked as a duplicate of this bug. ***
*** Bug 177396 has been marked as a duplicate of this bug. ***
*** Bug 181172 has been marked as a duplicate of this bug. ***
I don't think a "continue anyway" button or a prefs panel would be appropriate
for port blocking.  It's generally bad to have too many warning dialogs ("dialog
fatigue", "path of least resistance", "most users don't read dialogs", etc). 
Also, in the case of port blocking, the risk of clicking "continue anyway" is to
someone other than the user who makes that choice.

I like some of the other ideas:

1. Unblock port 1080, which bbaetz claims is not exploitable because socks is a
binary protocol (bbaetz, bug 85601 comment 25).  Leave other ports blocked,
because web servers on those ports are extremely rare.

2. Unblock external GET requests to 1080 and allow 1080 servers to POST to
themselves, but continue disallowing external POSTs to 1080 (Wesha, bug 92769
comment 26).

3. Allow users to type foo:1080 into the address bar, but continue to not follow
external links to those URLs (Bartosz Wucke, bug 85601 comment 26).  This would
be similar to what Mozilla does for file and chrome URLs.

4. When networking errors dialogs are replaced with placeholder pages (bug
28586), there will be room for more text and maybe even a "more info" link.
If Mozilla ever becomes popular and it blocks everything but port 80, then all 
the nasty server will just move to port 80 and those with internal company 
servers on alternate ports will just use IE since Moz "won't work".  

This is a very weak "security" feature that has been causing more anoyance than 
solving problems.

I think the ultimate solution would be one "firewall style" manager, that would
incorporate image blocking, popup blocking, parental advisory, cookies
management, javascript/java/plugins permissions, AND allowing/denying access to
selected ports/hosts, similar to my idea from comment#22 only much more
advanced. For now different security issues are handled by many separate
elements, while one strong tool would be ALL I need. I block banners from a host
- I still get empty popups. I block popups - it stores cookies. I want to
disable any connections with *.doubleclick.* and enable any connections to
myotherbox.myownlan.someisp.net - why do I have to look in 10 different places?
Adding sensible defaults, would be definitely desired though...

This is a subject for a separate bug though, and a BIG one. Definitely not the
work I could do... I had a look at the sources, at what I need to know, what
skills do I need to actually fix bugs in Mozilla myself and now I can say with
authority "this is far above my skills".

Please assign this bug to someone else. I still can do minor help tasks like
bugathon testcases or submitting new bugs, but keep me away from the source...

looking at activity log, ben@netscape.com was the previously assigned owner. 
Returning ownership to him, per current assignee's comments.
Assignee: bw → ben
Whether GUI is going to be implemented for this or not, there should be a way of
enabling all ports for people doing development work involving "strange" ports.

So, ideally, the network.security.ports.banned.override preference should be
able to except something like "*", and the new GUI should enclude a check box or
something to enable all ports so that they don't all have to be typed in.

What are all the disabled ports anyways?
Chad, this isn't quite the forum for questions like this.  in the future, you 
should try posting to the public newsgroups.  However, since you asked here, 
this is the answer:

The list of blocked ports is here:

http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsIOService.cpp#87

Any protocol handler (http, ftp, etc.) can override these defaults however, at 
least for http, it doesn't.
I hit the same problem with 3ware management tools for disk arrays. Telling
people to hack userprefs isn't a viable solution. Fortunately konqueror and
other browsers get this detail right (although whether they have other holes
because of it is another question)
*** Bug 235922 has been marked as a duplicate of this bug. ***
I think the ultimate consensus going around by the USERS (not the developers) is
that we would like a button to completely disable this thing. We don't need an
elaborate management system to manage what ports are blocked or not.
Assignee: bugs → nobody
(In reply to comment #43)
> I think the ultimate consensus going around by the USERS (not the developers) 
is
> that we would like a button to completely disable this thing. We don't need an
> elaborate management system to manage what ports are blocked or not.

actually i'd rather have the thing disabled by default and add a button to 
ENABLE the thing. this sort of B.S. security feature is one of those things 
which push mozilla to the bottom of the list when it comes to choosing a 
browser for general use. thats why i still use I.E. 5.0 as my main browser...



I think either option is acceptable as long as the button/option is one of the 
options under preferences that can be set to on or off.  I'm assuming that I 
would not have to select it each time.
Port 1080, the only blocked port that got complaints, is now unblocked.  See bug
92769 comment 33.

This bug should be WONTFIXed.
This bug should be WONTFIX'd because it has too many suggested UI solutions. I'm going to take 
ownership and WONTFIX after 1.8a ships.

port 1080 is unblocked now.
about:config allows people to hack prefs very quickly, so the workaround is painless.

Also, a bug should say: "Add port banning to prefs UI" -or- "blocked port dialog should allow 
unblocking." I don't like a dialog box w/o a pref UI, because end users would be unable to change their 
block list w/o understanding about:config.
QA Contact: ckritzer → benc
Whiteboard: review for 1.8a
(In reply to comment #47)
> about:config allows people to hack prefs very quickly, so the workaround is
painless.

I strongly disagree.  Since network.security.ports.banned.override does not
appear in "about:config" in FireFox 0.8, there does not appear to be any simple
way for end-users to set this.  This is a show-stopper for Mozilla, since I have
a consulting client whose corporate web-services company offers their server
statistics web pages on port 87, which is blocked by Mozilla.  Their standard
advice is:  "We don't work with Mozilla, use IE."

Regards,
Andrew
(In reply to comment #48)
> This is a show-stopper for Mozilla, since I have
> a consulting client whose corporate web-services company offers their server
> statistics web pages on port 87, which is blocked by Mozilla.  Their standard
> advice is:  "We don't work with Mozilla, use IE."

I think my web service provider (webcentral.com.au) is the one you mention. I am
about to ask if they can change the port of my statistics server, but I'm not
expecting a positive response.

In any event, I don't think this security issue has been dealt with properly.
Surely what needs to be blocked is *sending data* to a non-standard protocol
port on a *different domain*. The general use of non-standard ports is not a
security issue, and the ports _should not_ be blocked.
*** Bug 319060 has been marked as a duplicate of this bug. ***
*** Bug 347393 has been marked as a duplicate of this bug. ***
This bug prevents using the major internet-banking in Baltic states.


It just says without any option for getting it work.

Port Restricted for Security Reasons
Access to the port number given has been disabled for security reasons.

The requested address specified a port (e.g. mozilla.org:80 for port 80 on mozilla.org) normally used for purposes other than Web browsing. The browser has canceled the request for your protection and security.

Seamonkey 2006091908
ezh: what sites/banks, and what port?
I discribed it here: https://bugzilla.mozilla.org/show_bug.cgi?id=347393

I'll nominate this as a 2.0 blocker since this will hit millions Hansabank online users in Baltic states.
Severity: major → critical
Flags: blocking1.8.1?
We're not going to block Firefox 2 on this, but nominating for a solution for future.
Flags: blocking1.9+
Flags: blocking1.8.1?
Flags: blocking1.8.1-
FF2.0 does not allow accessing banking accounts nor for business, nor for individual customers. In Estonia 20-25% are using FF and for 80% of internet users Hansapank is the home bank. 

We _DEFENETLY_should return to FF1.5 behaviour, since by now there is no lihgt way for allowing the usage of this port.

Please reconcider the dicision.
(In reply to comment #56)
> We _DEFENETLY_should return to FF1.5 behaviour, since by now there is no lihgt
> way for allowing the usage of this port.

Nothing changed between 1.5 and 2.0 with regards to port blocking, so I don't understand this statement. Are you saying that your bank works in FF 1.5, but not in Firefox 2.0 RC 1?
Bug 301762 added port 563 (and a few others) to the blacklist in nsIOService.cpp.  It was fixed on the 1.8 branch but not on the 1.8.0 branch.  So what ezh is seeing -- that a site using port 563 works in Firefox 1.5.0.x but not in Firefox 2 -- makes sense.
Someone suggested that instead of refusing to connect, we should probe the server with a simple HTTP request to see whether it is an HTTP server.  That sounds like a good solution to me.  It would need to be done on every connection, though, because of issues related to the lack of DNS pinning.  And I don't know if there's such thing as a "simple HTTPS request" that we can be pretty sure won't screw up a server using a non-SSL protocol.
Yes in FF1.5 or Seamonkey 1.5 2006050908 works fine, but the FF2.0 and modern Seamonkey nightly are blocking the port. I dunno what has been changed, but this is the fact I see on all my 3 computers...
Blocks: 347393
First thing that needs to happen here is that we need to come up with a spec for how this should work. Beltzner, dveditz, either of you offering to lead that?

Marking this blocking-, if someone offers to come up with a spec for this feel free to renominate.
Flags: blocking1.9+ → blocking1.9-
Someone said that the only blocked port complaints were received about was 1080. Let me add that the port that allows access to my bank login apparently is blocked, and that's a pain for me and several others. Note: COMPLAINT! 563 according to the release notes is the likely culprit, though my attempt to override that has not worked yet, from reading the comments here, I may have a syntax error. I echo what someone else said, putting in protective measures that make it difficult to impossible for non-tech users to do what they want causes people to switch to IE, even though it isn't as good generally.
Sounds like more censorship on behalf of mozilla:
"Firefox has canceled the request [to port X] for your protection."

What next, "Firefox has canceled the request [to that website] for your own protection?"
With iceweasel 2.0.0.14 (haven't tested on official firefox builds or 3.0), the "blocked for your protection" page shows a "Try Again" button, which appears useless.  Why show the button if it doesn't do anything?
That's a bug -- bug 318648.
Say "NO" to CENSORSHIP!

Please allow users the option to uncensor ALL ports, not one by one in the about:config!  It is one thing for Mozilla to block ports and another for there to be no way to remove all of them without an half-hours work!

Please allow this option to block or allow all, certain, or all non-HTTP/HTTPS ports in the Options GUI.
This is retarded that this lasted so long.  Was Firefox trying to implement gestapo 'vista' esc security measures before Vista even was?

If I want to go to a site at a port I wanted, that is my business.  Deny a site because of certain ports are 'suspect'?  entirely deny browsing because of suspect ports?

You might as well deny port 80 then, since there are more bad sites on that port than any.  Deny a simple user interface to remove this internal denaial... sure, alienate any regular user.

This is full BS, and any project Manager or Developer who thought this was good, should take courses in usability.

If I need a security product, I will use one (and I do).  That is not the purpose of a browser.  It will never do it right, and clearly hasn't in this case.

Case closed.
Has anyone who matters considered this bug anytime recently?

If not, can we somehow request a re-review of it?

Perhaps this bug is ready to be re-triaged.
I missed tdis bug when I was posting my own similar one, which has been closed as a duplicate (#480908). I have copied here my own final comments on the issue

In this instance, trying to legitimately access a website running on a port
which Mozilla has blacklisted because of the VU#476267 is certainly a laughable
'security' issue. G-Mail was used as an example here to replace a corporate
intranet address which I did not have permission to publish. The fact that
there is no *obvious* way to bypass this alleged protection without having to
mess around in about:config is certainly a bug. We can allow exceptions for
'bad' (or self-signed) certificates relatively easily (albeit with more hoops
to jump through than I would like) - why not in this case? And why has the
ticket that this bug has been marked as a duplicate of been outstanding for
years?

I'm prepared to work on and submit a patch to resolve this issue as it effects so many users - is this something Mozilla would be open to?
(In reply to comment #69)
> Has anyone who matters considered this bug anytime recently?

We still believe port blocking is the correct default policy. We still believe that the need to adjust this setting is too rare to warrant Firefox UI other than the existing about:config prefs. You may have better luck with SeaMonkey which traditionally has targeted an audience supportive of richer preference control.

The fact that no one has written an Addon to tweak the defaults or create a better UI tends to reinforce our belief that this is not a feature to sink our time into.

(In reply to comment #70)
> In this instance, trying to legitimately access a website running on a port
> which Mozilla has blacklisted

Spec-abiding websites don't live on ports < 1024 (other than the reserved 80 and 443) and should not be affected.

> The fact that there is no *obvious* way to bypass this alleged protection
> without having to mess around in about:config is certainly a bug.

I could respect an argument that it's "missing functionality" or even "bad UI" (which is why this has not been closed WONTFIX) but it's not a "bug".

> I'm prepared to work on and submit a patch to resolve this issue as it effects
> so many users - is this something Mozilla would be open to?

Depends on how you do it. If you go off and write your own fait accompli and then stick it in the bug it's likely to sit and rot. Two other approaches that would be much more effective:
 1) storyboard the interaction and get input from the UI owners before
    coding, or
 2) write an Addon and then point at its popularity as proof it's a
    needed feature, as well as getting some real-world feedback on the
    usability of your design.
I got the message "Access to the port number given has been disabled for security reasons.", for port 80 (which is not in the list of blocked ports...)

I don't have a 'user.js' file, nor a 'all.js' file on my computer. The only one I have is 'prefs.js', which I tried to modify and it didn't work.

The url I was trying to reach gives access to a webcam installed in my kid's kindergarten.

Is there a (simple) solution ?
It's pretty simple.  I should be able to go to what ever site I want on any port I want.

To block certain ports for my safety, you might as well block 80 and 443.

This not the point on Firefox.  If you want a security program, you have tons of choices.

If this initiative wants to make a port security program, then make one.  Don't sneak it in as a useless hidden addition to the browser.
ea.andre, that's pretty weird!  If you search about:config for "network.security.ports" do you see anything bold?  You could try resetting those prefs.
@Comment #74, and others, there does not appear to be any way to bypass this. The "try again" button that appears when the "Access to port...has been deleted" message does nothing (as documented in bug 318648) and the work-around to modify all.js or user.js to permit access to the blocked port does not exist in Version 2, apparently. We run a SCADA project for a public agency and being able to access an httpd on any port is important.
QA Contact: benc → toolkit
Is there any problem to add one button?
(In reply to comment #71)
> The fact that no one has written an Addon to tweak the defaults or create a
> better UI tends to reinforce our belief that this is not a feature to sink our
> time into.

That's right: the corporate environments with huge rollout potential where this bug has proven critical aren't going to look for an extension or futz about with writing their own; they're going to pass and look for a different browser that doesn't require them to jump through hoops to ensure basic functionality.

I know in the organizations that I work for even the people running Firefox "illegally" are starting to put it aside for other browsers specifically because of this type of thing.
Depends on: 341636
(In reply to comment #78)
> That's right: the corporate environments with huge rollout potential where this
> bug has proven critical aren't going to look for an extension or futz about
> with writing their own; they're going to pass and look for a different browser
> that doesn't require them to jump through hoops to ensure basic functionality.

Thats an interesting point: corporate environments, on the other hand, won't be happy when users override the security warning caused by a malicious site and cause problems that way, so there should be a way to disable the UI if the admin wishes.
A little bit of perspective here, maybe to kick you guys into shape.

When I ran into this message, I instantly thought of
http://www.youtube.com/watch?v=8UNLJJN0vl8

"That's about the stupidest **** thing in the known universe that you could possibly be doing."

This feature offers zero security and tons of annoyance. Legitimate services run on blocked ports. Blocking them shouldn't even occur to you as an option, that makes no sense.

Thank you.
Cross protocol attacks are real.  I think this sort of problem will be diminished when bug 354493 is fixed.

I am having trouble following your perspective.  You assert that there are legitimate services that run on block ports.  It would be really helpful if you could give examples of what you are running into.  Maybe we are blocking a common port that should really be open.
Doug, I'd imagine just about every single person finding this bug ran into it while trying to access a legitimate service running on a blocked port, and these forty or so people represent a ton of others--particularly novice users--who were blocked from a legitimate service and gave up in frustration without finding the bugzilla. You suggest that there are no legitimate services that this blocks, but the eighty comments above contain plenty of examples.

Personally, I ran into the bug while trying to access a server running on a corporate intranet--a completely legitimate website that was mandated by my employer. The IT department's response? "Well, that's why we officially ban firefox." This one instance represents a thousand or so users affected by this nanny decision and who therefore use a competing browser.

How many of the other forty subscribers to this bug also directly represent a hundred or a thousand users turned away by the policy decision?
I understand the impact that you are suggesting.  What port was the IT dept. using to run a legitimate service?  As I stated before, cross protocol attacks are real and maybe we are being overzealous on the one you are hitting.
You want an example? Sure: An HTTP server deliberately running on a port of some well-known, easily attackable service that needs to be protected by this. Why someone should do it? Maybe because the school's firewall does not allow unfiltered traffic out on any ports except SMTP, POP3, IMAP and NNTP. For these, I wouldn't mind having to edit about:config. But there surely are other reasons why someone will do this, as seen above.

Not being able to add an exception for the single host AT ALL (without disabling the protection for that port altogether or compiling your own firefox) really sucks. A list in about:config of HOSTS to exempt from port blocking (instead of ports) would already be helpful.
(In reply to comment #81)
> Cross protocol attacks are real.  I think this sort of problem will be
> diminished when bug 354493 is fixed.
> 
> I am having trouble following your perspective.  You assert that there are
> legitimate services that run on block ports.  It would be really helpful if you
> could give examples of what you are running into.  Maybe we are blocking a
> common port that should really be open.

As Chris was saying, probably most of us are here because we ran into this problem. My specific case was trying to administer Polipo which runs on port 8123:
http://localhost:8123/polipo/status?
when I added this bug or one of its predecessors about 10 years ago, I worked for the German software company SAP. My task was to add browser support to their formerly non-browser software.
The server, I had to address was called ICM and it used the port 1080 as standard port.
Cause in those days it was'nt possible to change this block even by accessing about:config, the SAP Software Company decided not to support Netscape and Mozilla.
I suppose this port 1080 is still use by this software and therefore Firefox hasn't been supported for now 10 years.
So I just discovered this feature. Like many, I was annoyed to a point near anger. So I stumbled upon this bug, read through, sympathized with/facepalmed at the people calling it censorship, and of course was pushed even further into annoyance and anger territory.

But then I realized that there's a fix that doesn't add to the UI, doesn't change default functionality, and most importantly, removes lines of code.

First, remove the network.security.ports.banned.override preference.

I believe we can all agree on this. There should be no need to override anything.

Second, remove the hard-coded list.

I believe we can all agree on this. There should be no /need/ to block anything.

Third, give network.security.ports.banned a "sane" default value.

Of course, this is where we cease to agree. I, and many like myself, would of course abhor the idea that any given Transmission Control Protocol port number should be treated any differently than any other, just as with Internet Protocol addresses, or Domain Name Service queries. All should be treated equally, on principle, and certainly by original design, despite software utilizing these technologies not being able to tell an HTTP request from an SMTP request, and apparently not caring about the connection being authenticated in any manner whatsoever.

Of course, the feature has already been added, so we are not likely to find ourselves with a default preference value that we consider valid. Of course, nobody is going to take our complaints seriously, because it is merely our preference that the list be left blank. We are left only with the option of clearing that value in our own configuration files, never to be bothered by such defaults again.


If anyone has even the /slightest/ issue with this solution, then remove step 1 and get rid of that caveat. ;)
I like the idea of replacing network.security.ports.banned.override with network.security.ports.banned.  It would allow network admins to add or remove entries depending on the servers (web or otherwise) behind their firewall, as opposed to only being able to remove entries.
UNBELIEVABLE!!!  The HELL with what I want, the browser decides what ports I may and may not use!!  

What next?  You guys gonna come over and make sure I use my power tools correctly??  Mozilla table saw has decided the wood you are cutting is unsafe and will now shut down!  WTF!?!?

This should be MY decision, NOT yours!  I don't care if accessing that port formats my hard drive.  I should AT LEAST be given the chance to override it!!  Not this Draconian message of "F*** YOU! NO ACCESS!!".  It's just a GOD DAMN WEB CAM!!  SERIOUSLY!?

Now I have to use Internet Explorer.  It's pretty damn bad when Internet Explorer is capable of doing what Firefox can't!!
I too would agree this is an absolutely terrible decision on the implementers part.  At the very least, there should be a security exception added.  Ideally, any url typed into the address bar should not be blocked.  It is difficult to consider Firefox an "Internet Browser" when it ignores the use of the most basic specifications of IP protocols.  

Please restrict this feature to web service requests made within the pages or remove it entirely.  The security violation this seeks to fix should not be addressed by the browser, but instead by local administrators.  If insecure access is allowed to internal services, then those administrators should take accountability for their security breaches.  

Sadly, the approach taken to address this issue removes Firefox from the list of browsers used by developers and power users. We're not going to continue making these changes every time our environment changes, we're just going to pick a new browser for development and administration of systems.

If a maintainer is needed, I'll be happy to help.
Have to comment again:

Firefox is (as I am told) a browser... not a security program.  I have security programs.

Should I use IE or Chrome to go to the ports I want?
This blocking is ABSOLUTELY UNACCEPTABLE. These are totalitarian Nazi methods! YOU DO NOT GET TO DECIDE OVER MY HEAD WHAT’S ALLOWED AND WHAT NOT!

I demand this to be removed IMMEDIATELY!

And how retarded do you think your users are?
(Apart from you deliberately forcing them into stupidity by dumbing everything down like that.)
"This blocking is ABSOLUTELY UNACCEPTABLE."

This is absolutely correct. Devs keep dumbing down firefox, removing features, thinking they know better than their users, and then they wonder why everyone wants to go to chrome.
ill: Navid has had his account suspended for abusing our developers. Please don't say anything which will lead you to suffer the same fate.

This change was made in response to known possible attacks against a user's network. If you were able to explain the scenario which requires you to be able to use port 6000 from Firefox, perhaps something constructive could be done. But abuse is not going to get you anywhere.

Gerv
I'd question the efficacy of threats to enforce non-participation if it were relevant here.

(In reply to Brent Holowka from comment #91)
> Firefox is (as I am told) a browser... not a security program.  I have
> security programs.

I'd also agree more with this sentiment if I were aware that such a view could conceivably propagate through the Mozilla foundation; an awareness I find myself inept to perceive.

I'd like to reiterate my proposed solution from comment #87 with the added assertion that I can totally write a patch to this effect (to say or imply nothing of if it will be reviewed or applied whatsoever) if nobody already aware of this issue finds the motivation to do so themselves.

I'd be more than happy to do just that if I were readily convinced my proposed solution was agreeable in any way, or at least that nobody bothering to pay attention to this saw any significant flaws or other unacceptable items in the solution I propose.

I'd clarify that the overarching issue here is that the aforementioned "attacks" are only able to be propagated through ignorance on the part of the user and are thus inapplicable (read: bugs) to a non-trivial portion of Firefox users, if clarification were at all useful to the resolution of this issue and I believed in the possibility that someone might take said clarification seriously.

Beyond these five then/if statements, I can certainly provide a scenario which requires you to be able to use port 6000 from Firefox:

There is an HTTP server running on TCP port 6000 accessible through the IPv4 packet routing procedure.

This is not only a verifiable, realistic scenario, but also an easily inducible one.
> There is an HTTP server running on TCP port 6000 accessible through the IPv4 packet routing procedure.

Why would anyone want to do that, given that they have 32,768 ports to choose from? Someone could also run an HTTP server on port 25, but if Mozilla allowed web content to submit data to port 25, then every web browser could be (ab)used as a spam sending device. These ports are blocked (with a per-browser override option) because not blocking them leads to Bad Things. If you want a port on the list unblocked for everyone, you have to show how Bad Things won't happen.

BTW, Chrome does the same thing (actually, with a slightly longer list of ports):
https://src.chromium.org/svn/trunk/src/net/base/net_util.cc
I would be surprised and shocked if this behaviour were not standard across all major web browsers.

Here's the background again:
http://www-archive.mozilla.org/projects/netlib/PortBanning.html

Gerv
(In reply to Gervase Markham [:gerv] from comment #97)
> Why would anyone want to do that, given that they have 32,768 ports to
> choose from?

Actually it's double that number and as far as why... Well, someone might easily want to royally frustrate Firefox and/or Chrome users. They might also choose that port for sentimental or any other number of reasons. Maybe they like 0x1770 because it's almost symmetrical. The reasoning of every individual HTTP server running user on the internet is unclear to me. What is clear is that it is absolutely permitted by most, if not all, HTTP server software, not to mention tools that could force such a circumstance as ssh(1) is trivially capable of.

But the in-built capabilities of the lower networking layers seems secondary to the issue here. Especially in light of an offer to literally write a patch for (what I believe to be) a solution that virtually, if not literally, everyone paying attention can agree on.

> Not blocking them leads to Bad Things.

Yes, for users that are not actively aware of such possibilities. Much as I would love an "advanced mode" preference, I feel that is far beyond the scope of this bug report and probably also an unwise idea in light of per-technology solutions such as the one I've alluded to twice now in this comment.

I would also like to--if I am allowed--state that I am totally willing to write the patch myself if I can get anyone relevant to provide me feedback on if such effort is entirely useless and not worth the trivial effort it entails or if it seems to be an effective solution to the issue. Again, that solution being the one I proposed in comment #87.
> Yes, for users that are not actively aware of such possibilities.

Actually, no - the bad things happen to the targets of the spam, or the owners of the systems under attack. And whether a user is aware of this attack vector or not (and 99.999% would not be), they can't see if a hidden iframe is using their machine to send spam to port 25 on some mail server somewhere. How would you detect such a thing?

We are not going to take patches to change this functionality without solid evidence that they would not increase the risk to other systems on the network. 

Gerv
As politely as I am able, I would like to request that you read comment #87 in full because the solution I proposed doesn't actually change what is and is not possible in Firefox.

As much as I would love to discuss solutions to the recently hyper-exaggerated "embedding" problem of modern HyperText, including exact mechanics of how (not) to handle (or "detect") <i?frame src=>, <form action=>, and of course autonomous (and easily obfuscatable) free-form scripted HTTP requests, I feel that is beyond the scope of this bug report that I would like to see resolved in such a way as to not continually make work harder for users and developers alike. I can also see a distinct potential for such solutions to disable tension-inducing stress and confusion that would overall make events such as comment #93 far less common and much more manageable.

Again, and I really do not mean to repeat myself but, please, the solution I allude to can be found in full in comment #87. It does NOT describe a change that alters the security issue at hand, but it DOES describe a change that I believe to be valuable to a degree deserving of consideration.
Comment #87 is full of grandstanding, so it's hard to discern the actual proposal. Is it:

1) remove the network.security.ports.banned.override preference.
2) remove the hard-coded list.
3) give network.security.ports.banned a default value equal to the current hard-coded list?

If so, what advantage does that give? If that is not the proposal, then you must be changing _something_.

Gerv
Thank you and I apologize for any previous behavior on my part that was unnerving in any way.

Yes, that is my proposal and it has several useful qualities that I can assess.

1. It makes the list of banned ports readily apparent in-application.
2. It does not hide information from or inhibit the user in any way beyond a default preference value.
3. It gives the user an immediate and obvious method to permanently imprint their preference into their application profile.
4. It actually shows up in an about:config search.
5. It gives the strong impression of empowering the user instead of the strong impression of restricting the user. (The comments here demonstrating strong evidence of the latter.)

It has been my observation that hard-coding restrictions directly causes severe frustration in non-trivial amounts, and a movement to "preferencize" any and all such restrictions in the manner I describe would greatly improve user trust and confidence in Firefox and the Mozilla foundation as a whole.
The restrictions are "preferencized" at the moment to exactly the same extent that they are under your proposal.

If I were you, I would produce a patch and ask for review from one of the networking team. This seems like the quickest way to find out what they think of your proposal, and whether it's worth the disruption. Remember to write migration code.

Gerv
Is there any simple way to override this banned port list to just allow ALL ports? The closest thing I've found is to create that missing network.security.ports.banned.override preference with the list from https://www-archive.mozilla.org/projects/netlib/PortBanning.html
1,7,9,11,13,15,17,19,20,21,22,23,25,37,42,43,53,77,79,87,95,101,102,103,104,109,110,111,113,115,117,119,123,135,139,143,179,389,465,512,513,514,515,526,530,531,532,540,556,563,587,601,636,993,995,2049,4045,6000

It seems like this issue has been known ever since it's implementation and reading through all the past comments, it's pretty clear that FF devs want to play the helicopter parent role here, even so far as turning down offers for assistance.

I don't need a daddy or mommy to watch out for me, thanks.
Flags: needinfo?(wleung)

I don't think we will make any change to this now.
Closing and restricting to "editbugs" permissions to avoid the me-too comments.

Flags: needinfo?(wleung)
Restrict Comments: true
Type: defect → enhancement
Keywords: helpwanted
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Duplicate of this bug: 1803583
See Also: → 1803583
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: