From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010725 BuildID: 2001072508 Attempt to access http://metaserver.netrek.org:1080 produces an "Access to port number given has been disabled for security reasons" dialog. Other web browsers are able to access this site without any problems. Reproducible: Always Steps to Reproduce: 1. try to access any http: url with port 1080 2. duh! you cannot! Expected Results: There should be no "banned" ports. Period. The browser should not censor web sites (even based on their administrator's bad taste in picking port numbers). At the very least, the error dialog should have a button "please let me see this site, just this once, please, please, please". Or the dialog should give clear instructions on how to unblock this port.

-> dougt Theres a pref you can override, but it won't work on a per-user basis.

Amazingly fast reply, but I am still unhappy. I still think this is a show-stopper bug- valid urls are unconditionally blocked for no obviously good reasons and the user is not given any clue that (a) the problem is local to the browser, (b) that it *can* be unblocked, and (c) how to unblock it. (and to add insult to injury, the list of blocked ports is "secret"). You and I may agree on a list of "bad" ports, but the Net is big, and somebody somewhere would have the bad taste to put useful information on a "bad" port.

Konstantin, I agree with you that the dialog and UI of this functionaltiy should be more appealing. There is a bug with respect to this (85601). If you would like to override this port, you can add the preference: network.security.ports.banned.override with the parameter being a list of tab delimited ports that you want unblock. Also, this list is not secret. The list of sites is here: http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsIOService.cpp#59 Since there is a workaround and another bug for beefing up the UI, I think that this bug should be marked WONTFIX. I hope you understand. Bradely, can you add this to the release notes?

Is port 1080 exploitable through http? A lot of people have been asking on the newsgroups why port 1080 is blocked, and it would be nice to be able to answer with either "it's exploitable and here's the exploit" or "it's not exploitable through http, so we'll make an exception to allow *http* connections on port 1080".

I can't answer that, but it is the default application port for SOCKS V4 and V5.

Its probably not, but I know that having said that someone will give me an exploit...

*** Bug 128967 has been marked as a duplicate of this bug. ***

*** Bug 135765 has been marked as a duplicate of this bug. ***

*** Bug 144892 has been marked as a duplicate of this bug. ***

Guys, forgive me, but this WONTFIX stuff sounds like BS to me. Like, "we blocked this port so to not let hackers exploit it, but there's a way to unblock it.". What's the idea behind the blocking then? Do you think hackers are clever enough to write the exploit for SOCKS and stupid enough to be unable to unblock the port in Mozilla at the same time? Why should they even bother with mozilla when they can get IE or Lynx? That just reminds me of making an armored door and leaving the keys under the rug. :/

You must local access to your HDD to unblock it. And you must find the Profile with his random string. It's too late for everyhing if a exploit can access your local profile.

Well, we're talking about different things, no? The idea behind this port blocking is not letting me to use Mozilla to connect to that port on _remote_ server. It has nothing to do with my local HDD. Even if I have it all write-protected, I can use any other browser; I can use telnet, I can use a good load of other means to access that port. I don't see why should I choose Mozilla to carry out my evil plot of penetrating that port on some remote server. The software that protects ports is called firewall. Mozilla is not a firewall; it's a browser. I don't see why browser should have pieces of code in it that prevent me from browsing. :(

*** Bug 147890 has been marked as a duplicate of this bug. ***

Agreed completely. Wanna block ports? Add a separate component "Firewall". I really hate when my software tries to be smarter than me. And how, by accessing services of Daytime, QOTD or Discard you can compromise your security, is completely beyond me. Usually, if the attacker wants to, they will be running their exploit on some random "high" or unused port. This misfeature is highly annoying. I vote for reopening it and removing the monster. Instead of it, just patch the browser's possible vulnerablities.

Bartosz: if you agree, please use one of your 10 votes to vote for this bug, like I did (see the link called "Vote for this bug" right above the comment entry window.

Just forgot to do so. And just in case of mozilla being dangerous to other servers, it's not our task to protect them from the outside world. If Mozilla was used as DDoS tool (some 10% of browser market coverage required :) most probably it would be used to attack unblocked ports - the most important ones, like www or ftp. In the other hand, if the attacker tried to exploit bugs in server software on custom services, it's the admin's fault that the software isn't patched and the ports open, and besides that I can imagine several much better tools than Mozilla to perform such an attack.

See http://www.mozilla.org/projects/netlib/PortBanning.html

Forgive my bluntness, but this is BS. Why should one use Mozilla for such an attack, when they can use with equal, or even better results MSIE, Opera, Lynx, Telnet, not mentioning a handful of much more suitable tools for such a naughty activity that DO NOT have that kind of port control. Again, it's firewall's job to do port blocking, not browser's. If somebody's sysadmin is moron, no browser could really help. And, talking of network.security.ports.banned.override stuff, that just reminds me of locking your door thoroughly and leaving the key under the welcome mat. :/

The issue isn't someone attcking the site - thats trivial to do with telnet, or something. The issue is going to a page wihch makes _you_ attack the site, without being traced back to the original person - ie a distributed attack. That said, however, I do disagree with blocking 1080, because ns4 didn't. I lost that argument with dougt, though.

A little bit more sense - but, considering that the paper describing the vulnerability, says only about ftp connection or POST request, let us do http GET connections to these ports freely, pleease? And, talking of a distributed attack: a) To perform a successfull one, the bad guy should plant the code onto a website that is visited by a whole damn lot of people. If that's something like ebay or google or so, that's THEIR security problem, not mine. Peck on them. b) If that's some untrusted website, it's the problem of the people who came there (and most of them use MSIE anyway, BTW). Peck on them. c) If you're getting attacked that way, mail anybody the attack came from, accroding to your logs, and check their browsing history Mozilla keeps for a week or more. Find the originating website and peck on them. In common sense terms, it's like adding an inch thick rubber coating to your hammer, leaving just a tiny hole for the nail to have some contact with the hammerhead. Reason? "Hammers may be used to kill people". Makes some sense, too, no? But for me, potential victims wearing helmets would make much more sense.

I'm reading the document concerning the vulnerablity, referred from the "port banning" page. From what I see, first off, it's only about POST. GET (including forms) is safe. The vulnerablity when concerning email is trivial. If the mailserver is an open relay (even only for certain domain) the From: field cannot be trusted, the real originator appears under "Received:" header. If the mailserver correctly requires username and password, the attacker is helpless. <quote>3.3. Vulnerable protocols:(...) FTP, SMTP, NNTP, POP3, IMAP, IRC.(...) There is no way to use this attack on "binary" protocols. </quote> Additionally, if any of the above protocols requires password, the attacker is helpless. AFAIK only IRC doesn't have such potential and disabling IRC automatically disables all online java IRC clients. I think that in this certain case, the user attempting to post any data to given port number should be simply presented a requester the type that appears when entering/leaving https://. This way no worm unseen would be able to send its data and the user would be given a chance to prevent it, offending page will be located easily and no functionality would be broken. Is it really such a problem to change the text in the "Access to this port..." requester, and add a button of "Proceed anyway"? (eventually add "Never display this dialog for this protocol again" checkbox, which would add the pref. It's almost all there.

Yes, if the machine requires username/password, then this can't be used. The number of open relay mail servers out there is rather large, though, and posting to a server called 'mail' would probably work in most organisations, or for a large number of home users, in fact. NS4 blocked all of the ports mozilla blocked with about 3 exceptions, and the only one which people complain about is port 1080. I'm going to REOPEN this, because I think that blocking 1080 doesn't help. dougt is free to disagree again, in which cause he'll reresolve it again...

Just like Bartosz, I hate when software tries to outsmart me, and when I don't have control over what's going on on my very own computer. To reach some agreement between us and those who is all that afraid about the security issues (though again, the only browser's responsebility is to not let anybody gain control over the computer it runs on!) , I would suggest adding the "Proceed anyways" button to the messagebox in subject, that will have the effect at least until the browser is exited.

Wesha: I think this feature is an improvement. I'm not on the security team, but in their defense, I don't think that issues like "your marketshare minimizes the chance someone will exploit this" or "everyone else could be still exploited too" are logical arguements. If you don't like this feature, that's fine. What you have said is something like "you should ship or deploy your mail server as open relay because everyone else is doing it too..." If you want to talk specifically about blocking port 1080, lets talk about sistuations where this would be open on a network, that it is hard to attack SOCKS servers, etc. If you want to rant about the port-blocking feature, that probably belongs in a newsgroup.

I would much rather solve this bug by providing a better UI than allowing general access to port 1080. thoughts?

1) Let HTTP GET through on any port, as the vulnerability is specific for FTP and HTTP POST 2) Two buttons on the current security popup window, "Let me through nevertheless" and "Cancel", the latter having focus by default (measure against click-everything-through idiots) 3a) Checkbox, "Allow connecting to this site on any port" or 3b) Checkboxes, "Allow me connect to protected ports until the end of my current session" and "ALWAYS allow me to connect to wherever I want" (latter for advanced users who understand what that security bulletin is about).

Seems we came to about the same conclusion as on Bug 85601 Let's resolve this as dup of 85601 since the solution seems to be the same for both cases.

Yup, the Comment 21 for Bug 85601 makes a purrfect sense. Let's dup this one to it and go from there?

no arguement from me. Lets get some votes on 85601 and start talking ui design. *** This bug has been marked as a duplicate of 85601 ***

*** Bug 192112 has been marked as a duplicate of this bug. ***

IMHO some of the developers of Mozilla seem to be sawing on the perch they are sitting on. Once someone has discovered that Mozilla fails in such simple problems, they *will* obviously move to another browser (MSIE in most cases) and when Netscape - or whoever - wants to cancel the Mozilla project, because the Lizard could not assert itself on market, they might tend to do the same as some of the Netscape Navigator "advocates" did 4 years ago: saying that MSIE has a high market share because it is shipped with the OS. What a rubbish! I would recommend to listen a little bit to the user requests and satisfy at least the most important needs, and deactivating an unwanted "feature" is quite important!

We don't want an unsecure browser only because you have a problem with this. You can always disable this blocking with a hidden pref (see the release notes).

Fixed in bug 239121 after I sent a message to the security group. Reopening from "duplicate of bug 85601" (???) to mark as a duplicate of bug 239121.

*** This bug has been marked as a duplicate of 239121 ***

V/dupe.