1995-10-09 - java security concerns

Header Data

From: cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis)
To: perry@piermont.com
Message Hash: f270343a273389ca625611cc3855f2bae356676ac27716d94a85079c6f15ded9
Message ID: <9510091642.AA28211@pepper.Eng.Sun.COM>
Reply To: N/A
UTC Datetime: 1995-10-09 17:11:17 UTC
Raw Date: Mon, 9 Oct 95 10:11:17 PDT

Raw message

From: cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis)
Date: Mon, 9 Oct 95 10:11:17 PDT
To: perry@piermont.com
Subject: java security concerns
Message-ID: <9510091642.AA28211@pepper.Eng.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain



Perry pointed out the standard set of concerns that anyone should have with
Java. About the only thing I'd care to dispute at the moment is that Java
is a "large complicated" application. It is in fact less than 20K lines of
C code. And while it is true that applications of even this size are
difficult to prove safe, there has been an effort to break that problem
up into components such that each "layer" can be proven safe and where
that layer is used that safety carries over. Let me give you an example:

There are three "parts" of the Java system:
	o Java Bytecode
	o Java Runtime
	o Java Virtual Machine.

At a "meta" level there is the Java Language and the compiler that converts
it into byte codes however for the purposes of a security discussion those
are irrelevant since the browser in this case receives byte codes and the
compiler at the other end is presumed suspect.

So one way to approach this analysis is to look first at the bytecodes. One
of the things you will discover is that Java is *not* a general purpose 
language. It lacks crucial features such as introspection and anonymous
memory access. So you might ask "How can anyone write anything useful in it
then?" and that is a fair question. The answer is that it does have one
loophole and that loophole is the 'native' keyword on a method description.
Basically, if you need a general purpose feature (like object inspection)
you can get it with a native method. "So I write a native method to delete
your files, what does that buy me?" you might ask. Well Java is also a 
_late binding_ language. Thus the binding of external method references
(which native methods are by definition one) can be identified at bind/link
time (which always occurs on the client) and optionally rejected.

The next level of inspection is all of the classes that, through one of their
methods, actually call a native method. Those can be analyzed closely and
there are relatively few of them (about 28).

The final level of inspection is the virtual machine interpreter. Its 
operation as a giant switch statement can be inspected for valid code
design. It isn't all that large and a team of three can inspect it in under
a week. 

If the layers work, the system works. We encourage any questions on security
or identifying any "holes" to be sent to java@java.sun.com for our immediate
attention.

--Chuck



However, Java is also late





Thread