Date: Wed, 23 Mar 94 13:22:20 CST
Message-Id: <9403231922.AA12852@boombox.micro.umn.edu>
From: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>
To: moore@cs.utk.edu, uri@bunyip.com
Subject: Re: gopher URLs (was Re: how to make progress ...)
In message <199403231823.NAA09713@wilma.cs.utk.edu> Keith Moore writes:
> > I must be a little slow this morning, because I don't understand what you
> > are saying. How exactly might a gopher URL be used to spoof other
> > protocols?
> > Can you write up a concrete example of what you are trying to avoid so I
> > can be sure I understand what you are talking about?
> >
> > You should also write up the wording you propose to add to address this
> > issue... since I don't know what you are talking about I can't figure out
> > how to rewrite the spec.
>
> The easiest example is a gopher URL which specifies port 25 on
> some machine, and contains a selector string like
>
> HELO%20localhost%0D%0AMAIL%20FROM:<user@domain>%0D%0ARCPT%20TO:< ...
>
> Someone trying to read such a URL from a client will cause a forged mail
> message to be sent from his site. This can cause all sorts of annoying
> effects.
>
I see now. Depending on how clients that resolve the URL are written this
affects both the current gopher URL and the proposed Gopher URL. The gopher
URL I proposed states that gopher selector strings can contain anything except
<tab> <return> <linefeed>... because Gopher servers return directory listings
to clients using <tab> as a seperator and <return> <linefeed> as a terminator
for an item descriptor. If the clients are written to carefully parse the URL
then you won't get in trouble, but with a sloppy client you might.
You could say that clients should reject the Gopher URL as bogus if within the
selector string section of the Gopher URL's parameter package, there is a coded
<return> or <linefeed>... but a better way of dealing with this would be to
say that all clients should reject all URLs that point at the well-known port
for sendmail. This would handle the potential problem for all protocols that
allow specifying a port number and send arbitrary information at the port.
> In general, any URL that lets you specify a port number and lets
> you send arbitrary stuff to that port, can be abused in this way.
>
Good point. It sounds like you want a general recommendation not to
have clients resolve URLs that might create do spoofed mail, so I think
you are really saying that clients should not dereference URLs that point
to port 25 (unless the URL is a sendmail URL, whatever that might be).
> For gopher, the best quick fix I've seen was to disallow selector
> strings containing newlines.
>
A more general and better fix is telling clients not to point at port 25,
since the real problem is that sendmail is awfully trusting.
Mark P. McCahill
gopherspace engineer/University of Minnesota
mpm@boombox.micro.umn.edu
612 625 1300 (voice) 612 625 6817 (fax)