1995-11-15 - Re: Netscape rewards are an insult

Header Data

From: fc@all.net (Dr. Frederick B. Cohen)
To: cypherpunks@toad.com
Message Hash: 0f2255c51ebd0558b827dd82b8d7fa54574cae841c63fe3a207a0d763a5a23a4
Message ID: <9511151215.AA20714@all.net>
Reply To: <199511151019.CAA18910@jobe.shell.portal.com>
UTC Datetime: 1995-11-15 12:18:56 UTC
Raw Date: Wed, 15 Nov 95 04:18:56 PST

Raw message

From: fc@all.net (Dr. Frederick B. Cohen)
Date: Wed, 15 Nov 95 04:18:56 PST
To: cypherpunks@toad.com
Subject: Re: Netscape rewards are an insult
In-Reply-To: <199511151019.CAA18910@jobe.shell.portal.com>
Message-ID: <9511151215.AA20714@all.net>
MIME-Version: 1.0
Content-Type: text


> Alice here ...
...
> My post detailing a structural flaw in Netscape Navigator was announced,
> very quietly, to this list OVER ONE MONTH AGO.  And what has been done
> about it, by AT&T and/or Netscape??  Nothing. 
> 
> AT&T has its reputation attached to this code, as does Deutsche Telecom,
> as does Netscape.  The only "action" they've taken is to info-freeload and
> then do absolutely, positively, definitely ... nothing. 
> 
> Diddly-squat.
> 
> No one has taken any action whatsoever.

On a closely related vein, Sun has announced that they are severely
limiting some functions in HotJava - from Risks-17-45:

: The paper written by the two students at Princeton describes possible
: attacks on the alpha3 HotJava browser, which have all been fixed in JDK
: beta.  Granted, until this week, the source code for JDK beta wasn't
: available, so it's understandable that they analyzed the alpha3 source base.
: 
: We understand people need more information on the security model, and we're
: taking time right now to document the security story more rigorously.  A
: security FAQ, an updated whitepaper, detailed user documentation and
: detailed implementor's documentation are all being worked on.
: 
: ...
: 
: Access Control Lists are greatly restricted in beta,
:         as compared to the situation in the alpha3 HotJava browser. 
:         ACLs are initialized - only once - by the applet security
:         manager, and are not user configurable.
: 
:         For a file not on the access control list, an applet cannot
: 
:         - check for the existence of the file
:         - read the file 
:         - write the file 
:         - check the file type
:         - check if the file is a directory
:         - check the timestamp when the file was last modified
:         - check the file's size
:         - create a directory 
:         - rename the file
:         - list the files in this file (as if it were a directory)
: 
:         Applets cannot
: 
:         - create a FileInputStream 
:         - create a RandomAccessFile, either for reading or writing
:         - Open file descriptors
: 
:   2.  Sockets: 
: 
:         Applets cannot 
: 
:         - Create socket connections other than to its own host
:         - Create a socket factory
: 
:   3.  Loading/linking: 
: 
:         Applets cannot 
: 
:         - Create class loaders
:         - Access a package in the sun.* hierarchy
:         - Define a new class in the java.* hierarchy
:         - Link dynamic libraries using System.loadLibrary()
:         - Disable or override the AppletSecurityManager
: 
:   4.  Process control: 
: 
:         Applets cannot 
: 
:         - Define native methods
:         - Fork processes
:         - Manipulate threads or thread groups outside of the
:           applet's thread group
:         - Exit the virtual machine (e.g., the browser or the appletviewer)
: 
:   5.  awt: 
: 
:         Applets cannot
: 
:         - Create toplevel windows that don't have a warning banner
: 
: ...

I had a rather lengthy discussion with a gentleman from Sun at the CSI
conference last Tuesday night, and this announcement follows many of the
things we discussed very closely.  This kind of consistency between what
people say and what the company published is refreshing, and it restores
my faith in Sun's desire to do things well.  Of course there are still
some problems left unresolved:

:...
: It's very difficult, if not impossible, for a web browser to completely
: prevent denial of service attacks.  The JDK applet API doesn't claim to
: prevent denial of service attacks.  A "denial of service" attack is where
: someone writes an applet whose goal is to consume all available resources on
: your computer, forcing you to kill the browser you're running.  For example,
: someone could write an applet that creates a million pop-up windows.  The
: windows don't do anything, but creating a million of them might use up all
: the virtual memory on your computer and you'd have to kill the web browser
: to reclaim the virtual memory.
: 
: Before people engage in too much wailing and gnashing of teeth about
: how applets have been too severely restricted - 
: 
: We want to enable applets to do interesting things, including making
: socket connections, and reading and writing to the file system.  One
: way to enable that is to used a signed class loader.  When a trusted
: applet is loaded, then the applet could be granted permission to do
: some of the things they are prevented from doing by default.
: 
: The goal is to ensure that untrusted applets can't steal or damage
: information on a computer running a Java-enabled browser.  Later, we can
: allow trusted applets to do things that untrusted applets are not allowed to
: do.  Since an implementation bug in a trusted applet could open a loophole
: that could be exploited by an untrusted applet, design matters.
:...

Similarly, if your HotJava allows an insecure Postscript implementation
to interpret postscript files, you're still beat.

I do think that this response by Sun, regardless of the technical merits
of the particulars, demonstrates a desire to improve protection and a
willingness to listen.  My compliments for that.

-- 
-> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236




Thread