Re: solution time for www/smtp hole

brian@eitech.com (Brian Smithson)
Date: Fri, 13 Aug 93 11:34:33 PDT
From: brian@eitech.com (Brian Smithson)
Message-id: <9308131134.ZM22764@eitech.com>
In-Reply-To: Charles Henrich <henrich@crh.cl.msu.edu>
        "Re: solution time for www/smtp hole" (Aug 13,  1:22pm)
References: <9308131722.AA04889@crh.cl.msu.edu>
X-Mailer: Z-Mail (2.1.4 02apr93)
To: www-talk@nxoc01.cern.ch
Subject: Re: solution time for www/smtp hole
Status: RO

Ahem... the discussion of excluding of certain ports, versus restricting to
specific ports, versus disallowing certain strings in gopher accesses, misses
the mark, IMHO.  Please correct me where I'm out of line -- I haven't
researched this fully -- but I believe that the problem can be scoped down
rather quickly:


The general problem is that WWW makes it possible for a network service to
be invoked on an arbitary host, on behalf of an unwitting user.  Normally,
this is a Good Thing, and it's one of the Web's strong points.  However,
it is possible to misuse it by sending malicious commands to a service.

The only case in point that I'm aware of uses the gopher: scheme to send
malicious commands to some other service (smtp, mainly, but nntp was also
mentioned), using the optional "port" parameter in the URL to point to the
other service.  I haven't seen any discussion of possible misuse of a scheme
with it's _own_ protocol (e.g. sending nasty commands to a gopher server
using "gopher:").  I also haven't seen any discussion of possible misuse
of any scheme except for gopher:, presumably because gopher: is so free-formed
and does not have the familiar identified commands and responses (e.g. ftp).


If all of that is true, then we only need to worry when ( scheme <> port )
and when ( scheme == gopher ).  What we're worried about is that the actual
service on the port isn't a gopher server. So why not validate the server
iff ( scheme == gopher ) && ( port <> 70 ) ?

This might sound familiar -- I suggested it yesterday, but maybe it went
unnoticed because you only got one copy of the message :-)

Validating a gopher server is not straightforward, because the initial
connection to gopher doesn't return some nice string like "Hi, I'm gopher".
Maybe there's a gopher command which could be used to validate (is anyone
aware of such a command?).

Alternatively, you could look for _any_ returned string upon initial connection
and use that to decide that it isn't a gopher server, because gopher servers
connect silently.  This would at least rule out ftp, smtp, telnet, nntp, and
all other services which announce their presence upon initial connection.
Are there any other recognized services which do _not_ announce themselves?

-- 
-Brian Smithson                                          brian@eitech.com
 Enterprise Integration Technologies                      +1 415 617 8009
 459 Hamilton Avenue, Palo Alto, CA 94301 USA         FAX +1 415 617 8019