Date: Mon, 22 Jul 2002 20:09:00 -0500
From: John Goerzen <jgoerzen@complete.org>
To: bugzilla-daemon@mozilla.org
Cc: gopher@complete.org, bbaetz@student.usyd.edu.au,
	jgmyers@netscape.com
Subject: [gopher] Re: [Bug 71916] security problem with gopher and arbitary
 ports
Message-ID: <20020723010900.GA27682@complete.org>
References: <200207222335.g6MNZvl09279@mothra.mozilla.org>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200207222335.g6MNZvl09279@mothra.mozilla.org>
User-Agent: Mutt/1.4i
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


On Mon, Jul 22, 2002 at 04:35:57PM -0700, bugzilla-daemon@mozilla.org wrote:

> 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.

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 to
be 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 a
serious impediment.  Hell, let's remove https because trying to negotiate
SSL with a server that doesn't support it could cause a denial of service to
that machine.

What this comes down to is that you are either 1) using gopher as a
scapegoat because Mozilla's internal security is too lax to deal with remote
accesses in the first place (see bug #28327), or 2) somehow taking
responsibility for all the world's security problems in one application. 
The two seem oddly contradictory.

Meanwhile, you seriously hamper a useful protocol, violating standards left
and right, in a bid to be worse than IE at handling the easiest-to-handle
protocol you could come in contact with.  I'm boggled.

Tell me something: Why should we be prevented from accessing
nic.merit.edu:7043 (a useful and valuable collection of information about
Internet protocols, history, and evolution; 781,000 documents) or the
government of British Columbia, Canada (bcsc02.gov.bc.ca:65507, 149
documents), the Hungarian Electronic Library (gopher.mek.iif.hu:7074, 8726
documents), etc. just because of this purely theoretical vulnerability in a
third-party application, not even the fault of Gopher or Mozilla?

You are not talking about some small corner of the 'net with only a couple
of servers.  Cameron Kaiser's efforts to index Gopherspace have turned up
7,233,660 unique and verified selectors.  Gopher is still in active use, is
still useful, is still supported, is still being enhanced, is still being
actively developed, is still valuable to many, and is still important for
support 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 now
remove the port 70 restriction", I would be happy to work with you to
develop a less-Draconian solution, one that is less likely to cause such
harm.  There are many options -- the simplest being a confirmation box with
a checkmark for "don't show me this again".

-- 
John Goerzen <jgoerzen@complete.org>    GPG: 0x8A1D9A1F    www.complete.org