[gopher] Re: [Bug 71916] security problem with gopher and arbitary ports
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
On Mon, 2002-07-22 at 20:09, John Goerzen wrote:
>
> On Mon, Jul 22, 2002 at 04:35:57PM -0700, bugzilla-daemon@xxxxxxxxxxx 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?
It's not, if people stop wasting their time fixing a nonexistant Gopher
URL problem and spend more time patching their servers.
> Couldn't somebody use telnet to the same effect?
No, Gopher URLs don't specify anything but the server and port, to my
knowledge, and so are only used to connect to the server, not to send
any data to it.
> If it's a buffer overflow, the extra four "GET " characters are unlikely to
> be particularly helpful in mitigating the situation.
It's not even that, it's a *potential* problem with other server
software, not with Moz.
> 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.
The point was Gopher URLs and (ab)using the Gopher protocol can be used
to simulate virtually any protocol, including SMTP (read down a little
further on the comments, there's an example with SMTP).
> 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.
Number 2 hit it right on.
> 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.
Agreed, agreed, agreed. So am I.
> 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?
Oooh, thank you, thank you, thank you! More Gopher sites to book mark.
> 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.
Indeed. Stolz comment was a bit premature. I wonder how many times
he's actually used Gopher, or looked for Gopher servers. There are
plenty out there on port 70, and plenty out there not on port 70.
> 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".
Indeed. Restricting something permenently like that, when it's not even
a bug, is just wrong. The user should be able to use the software, and
that's clearly not the case with Gopher.
I think I'll go check up on bug reports, and see if one hasn't already
been submitted regarding the buggy Gopher URL bugfix.
--
Aaron J. Angel <aangel@xxxxxxxxxxxxx>
|
|
