71916 - security problem with gopher and arbitary ports

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[Bradley Baetz]

As blake was checking in gopher for me, jgmyers pointed out that the fact that
gopher allows connections to any port may be a security hole.

If an attacker can get someone to click onto a URL (like the above), then buffer
overflows on machines the attacker does not have access to (say, behind a
firewall) could theoretically be exploited, on any port (eg bind/apache/etc)

This problem occurs with gopher (rather than http/ftp) because there is no
header for gopher - the string entered by the user is what is sent (minus the
first letter). Finger has the same problem, but only accepts the defualt finger
port ins a url. I noticed this a while ago, but noone on IRC at the time could
come up with a reason for the "security reasons" comment in the finger source.

All gopher directory entries give both the host and the port for each entry in
the reply - this ability to transparently send the client from one server to
another is a feature.

For reference, apparently IE doesn't allow gopher to anything apart from port
70. This is commonly complained about as a bug - noone that I saw mentioned
security. ns4 doesn't allow appear to allow access to any url with NL or CR in
them, claiming that it does not "recognise". (You can still see the url in
apache logs if you get rid of the training %0D%0A) In any event, one line
exploits are still possible. lynx sends the string to any port.

Once gopher clears tinderbox, I'll arrange to check in a hack which just always
sets the port to GOPHER_PORT, ignoring the user's entry. This will do for 0.8.1.

I'd like to think about a better solution for the future though, which is the
purpose of this bug. Ideas?

Comment 1

[Bradley Baetz]

Attachment: quick solution for 0.8.1

Comment 2

[Peter "jag" Annema]

r=jag

Comment 3

[Marc Attinasi]

sr=attinasi

Comment 4

[Bradley Baetz]

Attinasi checked the hack in, so I'm reducing the severity - this is no longer a
security hole. Its now a missing-feature-problem. Updating summary.

I'll cook up a patch if someone can come up with a sensible idea. mstoltz?

Comment 5

[Mitchell Stoltz (not reading bugmail)]

I just talked this over with dougt, and we couldn't think of any better
solutions. Restricting gopher use to port 70 is probably OK - there aren't that
many gopher servers out there to begin with, so there are probably
infinitesimally few running on nonstandard ports, right? If, as you say, the URL
path is exactly what gets sent to the server, I can't think of any way to
distinguish legitimate requests.

Comment 6

[John G. Myers]

The channel should probably throw up an error page if it gets a url with a 
nonstandard port.

Comment 7

[Bradley Baetz]

mstoltz: We could refuse anything which isn't a visible ascii character, but
thats just restricting the problem. Note that this problem is easily exploitable
with, say, HTTP for buffer overflows - just get a very very large file.

I agree that its not a real issue, considering the number of gopher servers out
there.

jgmyers: I wish. Error handling in mozilla has "issues", and there are a couple
of bugs. HTTP is the only protocol which even reports a DNS error (although it
does so with a DocShell assertion right now). FTP doesn't report connection
refused, or file not found errors - it reports a status code of 0 in
TestProtocols, and Document loaded Successfully to the console from within
mozilla. (It currently crashes on a non-existant file - I think thats me though,
and I'm looking into it now)

Comment 8

[John G. Myers]

The channel could return a static page containing a message that non-default 
gopher ports are not permitted.

Comment 9

[[e-mail]]

I'm not sure I understand why the number of gopher servers is relevant to the 
threat risk.

If I'm reading this correctly, bradely and jgmyers are saying that you can 
create a URL that when clicked on, could send an arbitrary string to an 
arbitrary port. Is the presence of a gopher server even needed? If not, the 
threat of this is irrelevant to the existence of a single gopher server.

Comment 10

[Peter "jag" Annema]

Right, so the suggested fix is to limit gopher urls to the standard gopher port.

This could be a problem if there were a large number of gopher servers because
then there's could be "enough" people running gopher servers on non-standard
ports to warrant a better fix. So it wasn't a risk assessment but a "how much
time and energy are we going to throw at this" assessment.

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

Since we don't have a good security-confidential story on bugzilla.mozilla.org
just yet (Real Soon Now, hopefully), I'm marking this Netscape-confidential
after extensive discussion with the bbaetz, endico, and bryner.

Comment 12

[benc]

mass move, v2.
qa to me.

Comment 13

[Bradley Baetz (:bbaetz)]

after talking with mstoltz, opening this up, since the fact that it hints at the
port blocking problem doesn't matter, 'cause thats fixed.

Marking FIXED, since the original patch was checked in < 30 minutes after the
gopher stuff was. We could now remove the port 70 restriction, I guess. I won't
do so until someone complains, though.

Comment 14

[jgoerzen]

I think that this is a bad idea.  Cameron Kaiser wrote on the  
[e-mail] list:  
  
> While true, this should hardly be the responsibility of the client to  
> enforce -- this only masks badly written server software and makes it  
> less likely to find exploits. I strongly question the intelligence of this  
> decision.  
  
Additionally, I see little difference between this and http -- http simply  
adds "GET " and appends "HTTP/x.x\n".  Gopher prepends nothing and appends  
"\n".  
 
There are more Gopher servers than you might expect, and a number of them that 
do run on nonstandard ports.  Multiprotocol servers such as PyGopherD can serve 
both Gopher and HTTP requests from a single port, and it is not unreasonable to 
expect that you might see some of them answering gopher requests on port 80.  
In my own case, quux.org answers HTTP requests on port 70, but people could 
well do the opposite. 
  
Finally, certain Gopher servers (especially bucktooth) use this very feature  
to leap from gopherspace to the Web, since the original Gopher directory spec  
does not directly allow one to link to HTTP servers (since Gopher predates  
HTTP).  The request as listed in the subject of this bug is one way that this 
works.  So, you are directly breaking some links. 
 
I for one vote for re-enabling non-70 Gopher ports.  Consider me the "somebody 
that complains." 
 

Comment 15

[Aaron J. Angel]

Indeed, I have to agree with what seems to be concensus on the
[e-mail] mailing list, which is this change is a bad idea.  It does
indeed mask flaws in other software by fixing Mozilla, and that in itself is a
bit too crude for my tastes.  It would seem like Moz is protecting people from
something out of their control by making it a Moz problem, rather than what it
really is...it's not at all as much of a problem as you think it is.

In fact, I would argue (as I'm sure many Gopher users would) that restricting
gopher connections to a single port is more problematic than the problem which
it seeks to solve.  One part of the Gopher protocol, that was previously
mentioned, is that there are no headers.

Thus, one cannot for example, do name-based virtual hosting.  One can, however,
do IP-based virtual hosting easily, but who has enough IP addresses to devote to
Gopher servers, let alone Web servers?  Not that many, and certainly not the
majority of people that are involved with Gopher.  So, the only alternative is
to use other ports, which makes the most sense.

This is especially the case with me, for example, as I have two domains -- an
OpenNIC domain, under an alternative TLD, and thus not accessible to the
majority of people; and a legacy domain.  Now, given this change, I can no
longer use Gopher on ports other than 70 with Moz (which I would be prone to do,
when I start running two Gopher daemons).

On top of that, it's not uncommon for Gopher servers to run on other ports even
today, despite the lack (or so it would seem) of Gopher servers.

Stoltz wrote:
> If, as you say, the URL path is exactly what gets sent to the server, I
> can't think of any way to distinguish legitimate requests.

If you're looking into distinguishing legitimate requests, while your at it, why
not try to do so with http:// URLs too, and block the majority of common IIS
attacks that someone may try typing into the Moz' address bar, or even include
as a link on a web page to attack some server behind a firewall.  Blocking those
is about as similar as blocking Gopher on other ports, and the same is true for
both: it's not a problem with Moz.

Comment 16

[John G. Myers]

The fact that gopher doesn't prepend requests with anything is the root cause of
the problem.  An attacker can attack almost any protocol through a gopher URL. 
HTTP doesn't have this problem because it preceeds requests with "GET ", which
is unlikely to decode to legal syntax for any non-HTTP protocol.

Comment 17

[jgoerzen]

So what kind of problem is this going to cause?Couldn't somebody use telnet to the same effect?If it's a buffer overflow, the extra four "GET " characters are unlikely tobe particularly helpful in mitigating the situation.If you're thinking of a protocol like SMTP, servers will ignore the invalid"GET " line and still continue reading commands looking for more.  Hardly aserious impediment.  Hell, let's remove https because trying to negotiateSSL with a server that doesn't support it could cause a denial of service tothat machine.What this comes down to is that you are either 1) using gopher as ascapegoat because Mozilla's internal security is too lax to deal with remoteaccesses in the first place (see bug #28327), or 2) somehow takingresponsibility for all the world's security problems in one application.The two seem oddly contradictory.Meanwhile, you seriously hamper a useful protocol, violating standards leftand right, in a bid to be worse than IE at handling the easiest-to-handleprotocol you could come in contact with.  I'm boggled.Tell me something: Why should we be prevented from accessingnic.merit.edu:7043 (a useful and valuable collection of information aboutInternet protocols, history, and evolution; 781,000 documents) or thegovernment of British Columbia, Canada (bcsc02.gov.bc.ca:65507, 149documents), the Hungarian Electronic Library (gopher.mek.iif.hu:7074, 8726documents), etc. just because of this purely theoretical vulnerability in athird-party application, not even the fault of Gopher or Mozilla?You are not talking about some small corner of the 'net with only a coupleof servers.  Cameron Kaiser's efforts to index Gopherspace have turned up7,233,660 unique and verified selectors.  Gopher is still in active use, isstill useful, is still supported, is still being enhanced, is still beingactively developed, is still valuable to many, and is still important forsupport in a browser.If you remain concerned about the possibilities of the gopher protocol,despite the fact that Bradley Baetz wrote over a year ago that "We could nowremove the port 70 restriction", I would be happy to work with you todevelop a less-Draconian solution, one that is less likely to cause suchharm.  There are many options -- the simplest being a confirmation box witha checkmark for "don't show me this again".

Comment 18

[John G. Myers]

The issue is not one of buffer overflows.  The issue is that an attacker could
get a victim browser to proxy fairly arbitrary protocols, bypassing IP-based
access controls and firewalls.  Telnet does not provide such arbitrary-protocol
proxies.
 
Which "standard" are you claiming is being violated?  The IANA has allocated
port 70 to the gopher protocol.

Bug 28327 is irrelevant to this issue.  Such attacks could be launched using IMG
tags in HTML served through HTTP.

Comment 19

[jgoerzen]

RFC1436 specifies the Gopher protocol, and in section 3.2 asserts that "There is nothing to prevent secondary servers
or services from running on otherwise named servers or ports other than 70".  Further, it indicates that
"The client software can locate and retrieve any item by the trio of selector, hostname, and port."


You did not respond to my remark about HTTP "GET "; namely, that by inserting a newline as the first character,
one can cause many modern protocols to ignore the first "GET " with an error and then revert to exactly the behavior you'd get with Gopher.
It's mildly more difficult and slightly fewer servers could have this problem.

The bug I mentioned is not irrelevant; through mail is one avenue of attack.  You have mentioned another.


You have still failed to justify the need for this over-reaching stance when others (such as the pop-up box I mentioned) are
readily available to you.  You could also make a policy such as "no links to gopher servers on non-standard ports from IMG tags in HTML documents on 
HTTP servers".  It would be a lot less harmful.

Comment 20

[jgoerzen]

I'd also like to highlight some other statements made in this bug.


The original report states that this could not be a problem with HTTP or FTP because of the header.  This is not so.  Plenty of protocols could be 
made to easily ignore that header (SMTP for one, NNTP for another, with IMAP, it would actually be perfectly valid "GET LOGIN foo bar" is a login 
IMAP command).  So the original premise that this is only a Gopher problem is flawed.  Therefore, the conclusion that "gopher should be singled out" 
is equally flawed.


Mitchell Stoltz asserted that there are "infintessimally few" running on nonstandard ports.  I have shown you, in about 3 minutes of searching, over 
a million documents located on nonstandard ports in Gopherspace.


Bradley, you yourself say this is exploitable with HTTP.  Another reason that it seems weird to single-out Gopher.


Plenty of people want to run software on non-privileged ports for various reasons, including security.

Comment 21

[Quentin Smith]

Just added myself as a CC. I have to agree with jgoerzen and others. I myself
run a gopher server on a non-standard port, and I am lucky that I have spare
private IPs to provide redirection for Mozilla. There really is no reason to
only limit Gopher. Someone needs to REOPEN this bug.

Comment 22

[timeless]

no, someone needs to file a new bug. bug 158888 filed.

vrfy fixed 1.2 <[e-mail]> 13 Mar 2001 22:43

Comment 23

[John G. Myers]

Reply comments sent to the netscape.public.mozilla.netlib newsgroup.