Re: WWW Security Hole -- Bull! -- Bull!

Marc VanHeyningen <mvanheyn@cs.indiana.edu>
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: WWW Security Hole -- Bull! -- Bull!
In-reply-to: Your message of "Thu, 12 Aug 1993 16:15:22 -0400."
             <Pine.3.03.9308121622.A23538-b100000@ursa-major> 
Date: Thu, 12 Aug 1993 16:46:53 -0500
Message-id: <3339.745192013@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu
Status: RO
Thus wrote: Robert Raisch
>and someone else mentions that telnet itself is inherently unsafe.

How so?

>Let's face it folks, TCP/IP is unsafe.  We are not working with technology
>which protects us from the wolves.  Anyone who is seriously concerned with
>network security does not connect to the Internet. Period.

Fortunately, the above statement is not true.  If it were, or if it
becomes true in the future, the Internet will never be the tool that
its proponents envision it to be.  At least some people who worry use
things like firewalls, but firewalls don't defend against this
particular kind of vulnerability.

Of course, if word becomes widespread that WWW allows firewalls to be
bypassed and security weaknesses to be exploited, corporate sites
running firewalls will be unwilling to allow HTTP packets pass through
for their users.  This is why it's important to fix it quickly; we
have already heard from at least one large company who could get rid
of WWW if it's seen as insecure.

>        We can spoof sendmail.  Ok, fix sendmail and leave the tools
>        alone.  I can use a sledgehammer to break into a house so
>        we make the possession of a sledgehammer a capital offence.
>        What utter nonsense!

I can make no sense at all out of your analogy with prohibiting
sledgehammer possessions.  The problem is that it's possible for an
attacker to disguise your front door as a Wack-a-Mole game so that
people smash it in with sledgehammers without ever knowing they did
anything.  I don't think this is good.

>	It's simply not our responsibility to restrict the first truly useful
>	tools we have developed to manage the complexities of information
>	navigation simply because the network has embraced hacks and 
>	kludges instead of well developed services -- and if we take the tack 
>	that it is, we swiftly become lost in thousands of twisty little 
>	tunnels of paranoia, all alike.
>
>	Mime and a few people's well intentioned but misguided efforts 
>	notwithstanding.
>
>Apologies to any offended, but this is a hot button with me.

With me as well. I don't think you understand the severity of this.  I
could, had I the desire, probably manipulate some much-viewed document
(say, the finger gateway image stuff) I could cause several thousand
people to send mail without knowing it.  If the recipient of said mail
was someone significant (a smart server would vary it depending on the
location of the request; say, the president or CEO or their
company/University/etc.) and the contents of such mail sufficiently
bad (say, brutal rape and death threats) it would not be difficult to
envision having accounts yanked, being fired or expelled, and the like
to happen to many people before the truth was discovered (if it ever
was; depends how clever I was about it.)

The real problem (IMHO) is that Gopher is so broad that it's possible
to simulte other protocol's commands within it.  SMTP is arguably
sub-optimal as well.  But denouncing these things as ugly hacks (which
is possibly true) does not relieve us of the responsibility to do what
is possible to create a safe WWW environment for people.

The modifications needed are not terribly dramatic; disallowing
crlfs to be sent to gopher clients would be a significant help.
Prohibiting connections to ports <1024 other than 70 would help more,
though it might lose some functionality.  Fixing this bug need not
entail crippling anything as you claim.  What's important is that the
whole problem, not just this particular manifestation, be fixed.

In general, safety is more important than functionality.  Period.
That's why we have speed limits on roads, and that's why we need this
fix.

- Marc
--
Marc VanHeyningen  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here