158888 - implement better handling for gopher on non default ports

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[timeless]

spun off from bug 71916

please start by coming up with a good idea in the newsgroups (npm.netlib).

a good idea is *not* 'remove fix from bug 71916', it must address the concerns
raised in bug 71916.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

A good solution will also *not* involve a new warning dialog, with or without a
"don't ask again" box. Dialogs are CYA security, not real security.

Comment 2

[jgoerzen]

Consider this solution:  
  
Upon a gopher protocol request with a non-standard port, do this: 
 
1. Connect to the server at the specified port. 
 
2. Issue the following request:  \t$\n 
   That is, TAB, dollarsign, newline 
 
3. Read one like of reply.  It should either: 
   a. Match the regexp ^\+-{0,1}[0-9]+ 
      That is, begin with a plus sign followed by an optional minus sign 
      and a string of one of more digits 
    
   OR 
   b. Contain one or more TAB characters. 
 
4. If either 3(a) or 3(b) match, reconnect to the server and issue the real 
query; and save it as "good" so you don't have to repeat the test. 
 
I suggest using Mozilla's pre-existing history mechanism to decide whether or 
not to pre-validate a Gopher server running on a non-standard port.  (If there 
is at least one entry in history corresponding to the given host and port, 
don't bother re-testing it) 
 
This solution: 
 * Should work with all Gopher and Gopher+ servers 
 * Is automatic and requires no user intervention 
 * Minimizes impact of the extra check by performing it only once per server 
   and only for servers on non-standard ports. 
 

Comment 3

[jgoerzen]

Also, in no case should Mozilla attempt to translate a request for a port 
other than 70 into port 70.  This is really bad; if it refuses to connect to 
the nonstandard port, it should fail with a descriptive error message. 

Comment 4

[Bradley Baetz (:bbaetz)]

Gopher basically allows sending anything you want, since there isn't any
handshaking involved.

See the CERT advisory on using html forms to do this; its even easier with
gopher requests.

However, now that we have a list of blocked ports (bug 83401 and friends), this
could probbaly be removed, and the UI/dialog issues then become bug 85601. This
would cause the same ports ot be blocked as ns4 does.

mstoltz, does that sound ok?

Comment 5

[Mitchell Stoltz (not reading bugmail)]

Sorry, I don't understand. We fixed the gopher problem by adding the blocked
ports list - what are you proposing to remove?

Comment 6

[Aaron J. Angel]

I have to ask this question, just out of curiosity.  How many of you actually
use Gopher, let alone use *Mozilla* for Gopher?  Now, I don't mean to be rude,
but it seems very few of you even understand Gopher, or understand the issue
with Gopher URLs.

bbaetz puts it incorrectly I think: "Gopher basically allows sending anything
you want, since there isn't any handshaking involved."  I disagree.  Gopher
doesn't allow just anything; Gopher has a syntax; just because it lacks headers
does not mean it's freeform, in fact it's quite strict.  See the last few
paragraphs for one example where Mozilla fails to account for this.

Gopher is not the problem, if you can even call it that.  The problem is
partially the way Mozilla handles Gopher URLs, and mostly the way one can
(ab)use the way Mozilla handlers Gopher URLs, any type of URL really, for
malicious purposes.

Now, a quick review: Mozilla (& bad people) handle Gopher URLs possibly
insecurely.  The current fix is to restrict all Gopher URLs in Mozilla to port
70, because it's standard.  The current fix is, I have to say, wrong.  Previous
rationales for this fix include "Gopher is dying/not popular, who cares" and
"not many sites use nonstandard ports".

If you lean towards Gopher is dying and/or not popular, you might as well remove
Gopher code from Mozilla completely.  Even if you don't lean to that direction,
it should be seriously considered.

If you lean towards not many sites use nonstandard ports, you might as well
remove Gopher code from Mozilla completely.  Many sites *do* use nonstandard
ports, so frankly that makes this argument rather wrong.  I could probably come
up with many examples, past and present, if you like; I could even include the
reasons why in most cases.  The most common reason is quite simply lack of IP
address space.

Albeit rarely that I use Mozilla's Gopher client, I think it should at least
function reasonably well if you insist on keeping it.  I don't consider a
hard-coded restriction to port 70 for all Gopher URLs reasonable.  I can only
think of two reasonably good ways to get around this whole issue simply and with
concensus (and they could both be used together):

1) A bypassable warning dialog.  Think of unecrypted form submissions if you
need a little convincing; the two issues are quite similar.  This is a much
better alternative solution to the current "fix".

2) This should go without saying, but it seems someone has forgotten: *follow
standards*.  See bug 162050 for more info, which may make the next paragraph a
bit more clear.

Perhaps additionally disallow from the selector (which is the path of the URL)
CR and LF individually, and you have a pretty useless exploit tool.  Don't get
me wrong, I'm sure someone could find *some* creative way to exploit this, but
then again, someone can find some creative way to exploit anything.  This, at
least, prevents the majority of the risk, simply by following standards.  Then
the security issues largely relate external software, not Mozilla.

Comment 7

[Bradley Baetz (:bbaetz)]

Mitch - we added the blocked ports list, but that was _after_ bug 71916 was
fixed (severel hours before the milestone freeze). I'm proposing to back out the
fix for bug 71916 on the grounds that the blocked ports list now prtocets
against that problem.

Comment 8

[John G. Myers]

Blocked ports do not solve the problem, they merely limit its applicability. 
Refusing to dequote %0d or %0a (or any other control character) is a good idea.
 I also agree it is better to display an error than to map arbitrary ports to
port 70.

Comment 9

[jgoerzen]

If you take the blocking \n and \r route, you might as well also block \t,
because tab is not valid in a Gopher selector.

Comment 10

[jgoerzen]

If you take the blocking \n and \r route, you might as well also block \t,
because tab is not valid in a Gopher selector.

I should also point out that Gopher is charset-agnostic.  As long as you to not
use \n, \r, or \t, Gopher can serve up any character set.  Therefore, blocking
8th-bit data would not be a wise move, nor blanket blocking of ASCII chars < 0x20.

Comment 11

[Bradley Baetz (:bbaetz)]

\t, \n, \r, and \0 are being disabled in bug 162050.

Comment 12

[Mitchell Stoltz (not reading bugmail)]

Bradley, is there anything else we have to do here? Does Mozilla still support
Gopher, and if so, can we make the security restrictions less restrictive
without reopening the illegal-ports problem?

I'm going to send the bug your way; bounce it back if you feel it necessary.

Comment 13

[Bradley Baetz (:bbaetz)]

mitch: see my comment #7. We now protect against this better and more generally,
and we should be abel to remove the hack which was added just before the
milestone freeze a couple of years ago.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[Benn Newman]

It sounds there is better handling of Gopher (on all ports, not just `non-standard' ones, (as a side note, RFC 1436 says nothing about Gopher servers having to listen on TCP port 70, in fact, you can even run a Gopher `server' using UNIX to UNIX Copy). I think there is no reason to keep the `fix' from bug 71916 as  is also suggested in comment #13.

Comment 16

[Stian Sletner]

It is now 2006 and in Firefox 1.5.0.5 non-70 gopher requests are still broken.  It seems to me the concencus was this hack could be removed, so why is it still in?

Comment 17

[Aaron J. Angel]

Not only is it 2006, but it's fourth quarter and a new major version has been released.

I've upgraded to 2.0 only to find that it still blocks Gopher requests other than those for port 70, or with network.security.ports.banned.override set to a port I want overridden, the requests are rewritten for port 70.

These behaviors are vile and non-configurable.  Severity should be changed to normal:  this is not a request for an enhancement.  It is a bug report.

Comment 18

[Mate Nagy]

It is now 2008, and non-70 gopher requests are *still* broken. Again, requesting bugfix (as I have just argued in the nightmarish "remove gopher support" thread, right now Firefox is simply the best remaining Gopher client.. so it should at least work properly).

Comment 19

[timeless]

Attachment: implementation

So, I worked this out w/ biesi earlier this year.

it turns out that most of the stuff we needed has been around for years.

for testing:
gopher://www.polarhome.com:27070/

is gopher on an alternate port.

gopher://www.polarhome.com:27070/77/.index/gopher?hi

has a link to:

gopher://error.host:1/0

which triggers a security error

and

gopher://gopher.meulie.net/

still works.

I think I was considering doing more for this, like writing a full security protocol test suite, but that isn't actually related to this, and i'd like to get this patch out of my tree.

Comment 20

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 439785 [details] [diff] [review]
implementation

Actually, nsGopherChannel inherits from nsBaseChannel which already calls NS_CheckPortSafety. So you don't need the call here. (please test that, though)

Comment 21

[Jason Duell]

Note that gopher is going away as a core C++ impl:  see bug 388195.

Comment 22

[[e-mail]]

what is going on..... how come we can not download this search engine.. I want a real search enginie, not one that give me BS like Bing, google etc... I am so tried of looking off site for real news.