1996-02-22 - Re: BIG JAVA SECURITY HOLE

Header Data

From: “Perry E. Metzger” <perry@piermont.com>
To: “Robichaux, Paul E” <perobich@ingr.com>
Message Hash: 4ee6287f0e0d33b89e0163400974c919ee89840bf781c8f285a607867abb52d1
Message ID: <199602220338.WAA11137@jekyll.piermont.com>
Reply To: <c=US%a=_%p=INTERGRAPH%l=HQ6960221161902DK003B00@hq13.pcmail.ingr.com>
UTC Datetime: 1996-02-22 03:39:07 UTC
Raw Date: Wed, 21 Feb 96 19:39:07 PST

Raw message

From: "Perry E. Metzger" <perry@piermont.com>
Date: Wed, 21 Feb 96 19:39:07 PST
To: "Robichaux, Paul E" <perobich@ingr.com>
Subject: Re: BIG JAVA SECURITY HOLE
In-Reply-To: <c=US%a=_%p=INTERGRAPH%l=HQ6960221161902DK003B00@hq13.pcmail.ingr.com>
Message-ID: <199602220338.WAA11137@jekyll.piermont.com>
MIME-Version: 1.0
Content-Type: text/plain



Well, folks, I told you so. Sorry to be nasty about it.

> Date: Sun, 18 Feb 1996 23:57:02 -0500
> From: Drew Dean <ddean@CS.Princeton.EDU>
> Subject: Java security problems
> 
> We have discovered a serious security problem with Netscape Navigator's 2.0
> Java implementation.  (The problem is also present in the 1.0 release of the
> Java Development Kit from Sun.)  An applet is normally allowed to connect
> only to the host from which it was loaded.  However, this restriction is not
> properly enforced.  A malicious applet can open a connection to an arbitrary
> host on the Internet.  At this point, bugs in any TCP/IP-based network
> service can be exploited.  We have implemented (as a proof of concept) an
> exploitation of an old sendmail bug.
[...]
> A second, also serious, bug exists in javap, the bytecode
> disassembler.  An overly long method name can overflow a stack
> allocated buffer, potentially causing arbitrary native code to be
> executed.  The problem is an unchecked sprintf() call, just like the
> syslog(3) problem last year.
[...]





Thread