1996-03-30 - Re: Netscape 2.01 fixes server vulnerabilities by breaking the client…

Header Data

From: Steve Gibbons <steve@aztech.net>
To: tomw@netscape.com
Message Hash: cd73a5413f47924c00a06201bf418fed6294181ec307586c028498d6e8c3ee1a
Message ID: <009A015C.30D31580.701@aztech.net>
Reply To: N/A
UTC Datetime: 1996-03-30 16:04:08 UTC
Raw Date: Sun, 31 Mar 1996 00:04:08 +0800

Raw message

From: Steve Gibbons <steve@aztech.net>
Date: Sun, 31 Mar 1996 00:04:08 +0800
To: tomw@netscape.com
Subject: Re: Netscape 2.01 fixes server vulnerabilities by breaking the        client...
Message-ID: <009A015C.30D31580.701@aztech.net>
MIME-Version: 1.0
Content-Type: text/plain


(This was previously posted to cypherpunks list, I have expanded the 
distribution to the firewalls list due to the content.)

In Article: <315C8FCB.2781@netscape.com>, Tom Weinstein <tomw@netscape.com> wrote:
# Rich Graves wrote:
# > 
# > Now I suppose they'll want me to fix all the pages where I do a finger
# > with a gopher://host:79/0user Any chance this nonfix can be unfixed?
# > 
# > This nonfix was applied to the UNIX and Win32 versions; I haven't
# > checked the other platforms.

# It may be unpleasant, but it's a fact that there was a real security
# hole here.  There is a well known buffer overrun bug in finger that a
# lot of people inside firewalls haven't fixed.  Using gopher: URLs
# in IMG tags it was possible to do nasty things.  We tried to err on
# the side of permissivity, but finger was one port we just couldn't
# allow.  Yes, it sucks.  So does someone reaching through your firewall
# and running commands as root.

Let's look at this from the perspective of a company with a firewall:
    Q: Do I want my users dictating what's allowed?
    A: Probably not.

    Q: Do I want my software vendors dictating what's allowed?
    A: Maybe not.

    Real Q1: When are sun/netscape/browser-vendor-x going to provide
    standardized, secure, multi-teired configuration options?

    Real Q2: It seams to me that most of the standard TCP protocols that a
    gopher client can talk to should have similarly standard protocol-specifiers
    for the URL.  Browser vendors are in a perfect position to say "this lack
    of synchronization is a real problem" and "It's bitten us already" and to 
    take care of the problem by proposing RFCs.  

    Real Q3: (Somewhat off-topic) when are signed applets going to appear?

    comprehensive standards coupled with multi-teired configuration options 
    would allow real-world customers and their net-neighbors to sleep a little 
    better at night.

--
Steve@AZTech.Net





Thread