Closed Bug 92769 Opened 23 years ago Closed 20 years ago

Cannot access web servers on tcp port 1080

Categories

(Core :: Networking: HTTP, defect)

x86
Linux
defect
Not set
major

Tracking

()

VERIFIED DUPLICATE of bug 239121

People

(Reporter: olchansk, Assigned: dougt)

References

()

Details

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.
Assignee: neeti → dougt
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
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.
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...
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → DUPLICATE
*** 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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

*** This bug has been marked as a duplicate of 239121 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago20 years ago
Resolution: --- → DUPLICATE
V/dupe.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.