Plugging the hole
Marc VanHeyningen <mvanheyn@cs.indiana.edu>
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: Plugging the hole
Date: Fri, 13 Aug 1993 17:20:24 -0500
Message-id: <19059.745280424@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu
Status: RO
Trying to decide how to best figure out this issue is tricky; I'll try
to summarize and interject a little more and rant and rave a bit less.
:-)
As many have noted, low (< 1024) port numbers are assigned by the
IANA, and documented in various documents (RFC 1340 is reasonably
current.) In particular, ports 71-79 (except 76) and 81-89 are all
already assigned to other services; using them for other purposes like
additional Gopher or HTTP servers is just plain wrong. It is
(unfortunately) true that some server implementations for gopher and
HTTP do not allow sufficient functionality, and one way to enhance it
is to run multiple servers on different ports. This is a mere
limitation of particular software implementations, however; it is not
appropriate to violate port allocation guidelines because of
inadequate software. Fix the software. If multiple servers simply
must be run on the same machine, use high ports for the non-primary
ones.
The issue of using this variety of "trick" to make Gopher do clever
hacks like accessing finger servers and whois servers is a touchy one.
Is this trick really part of Gopher proper, or just a trick that
happens to work? If the former, we're obliged to support it (if
grudgingly, though it's no worse than the typing system...) A casual
reading of the Gopher informational RFC suggests that it's just a
clever trick, though it's hard to say since it's an informational
document and not a real standard. Despite all this, it's a good idea
to try to keep as much of this functionality as we can reasonably do.
Some have suggested that we keep a list of "dangerous/insecure ports"
I'll call these DIPs, and call that enumeration "The DIP list". I
believe a DIP list is not a viable approach; anyone who believes it
is should take a look at the RFC. It would be necessary to become
sufficiently proficient in the protocols used by each assigned service
to perform a review of the security implications of each. There are,
based on a casual count with sort -u | wc, well over 200 of them; I
don't know about you, but I don't wish to become an expert on 200
things and evalute the security implications of them all. This
evaluation would need be maintained over time as protocols are revised
and new ones arise, checking for DIP problems. Do you volunteer to
keep the DIP list current? I sure don't.
An alternative is to keep a "safe/approved port" list, or SAP list.
(Thus the battle is the dips versus the saps. :-) An enumeration of
ports which should be safe and useful (ones that look promising off
the top of my head include 7, 13, 17, 43, 70, 79, 80, 105...) is
probably easier to create, and less likely to have perpetual
vulnerabilitties due to being out of date. Omissions in SAP could
cause minor functionality limitations (how limited is an
implementation issue), while omissions in DIP could cause new
vulnerabilities.
While we're at it, there is now no particular security reason not to
allow some form of the tcp: scheme suggested by someone (Rob Raisch?)
a while back, since gopher: provides the equivalent functionality
anyway. So the idea could be re-evaluated.
The other proposed modification involves eliminating the ability to
encode multiple lines; to try to keep with the spirit, I'll name this
"Single Lines Always Considered Keen", or SLACK. The particular
attacks with things like SMTP and NNTP require multiple lines
separated by CRLFs to work properly; nobody has yet proposed a
successful attack with just a single line, though it could happen.
SLACK also has the distinct advantage of making our security situation
pretty much the same as it is for the rest of the Gopher world, which
increases the likelihood that Gopher folks will discover any potential
problems sooner, once we're in the same boat.
There are two different sub-portions of this plan:
- Patch the current problem, quickly.
- Come up with a more general approach to make sure other instances of
this kind of thing don't happen again
It's OK for these to be two different fixes, as long as fixing the
former doesn't lull people into a false sense of security about the
need to do the latter. The SLACK approach is probably the best quick
fix; it fixes this and shouldn't involve any loss of functionality.
Deciding other implications, debating DIP vs. SAP, and the like can
come after that.
- Marc
--
Marc VanHeyningen mvanheyn@cs.indiana.edu MIME, RIPEM & HTTP spoken here