Java

As long as people are mentioning Java, I just want to make the
prediction, one more time, that at some point someone is going to find
some devistating security holes in HotJava.

In order for HotJava to be completely safe, the Java security model
needs to be perfect (and it is way too complex to prove correct), you
need a perfect implementation of this perfect security model, no code
in the Java implementation outside the security code can adversely
impact the function of the security code, and there has to be no way
that a bug in the code outside the Java implementation can screw with
the internals of the Java implementation in such a way as to get it to
drop its security.

I don't believe that humans can produce something that satisfies all
four criteria given our current state of technology. Java is just too
complex a language for me to believe that it can have been perfectly
specified and implemented.

Enormous risk -- I really mean ENORMOUS risk -- is being taken in
order to add a little convenience in making web applications pretty.
Someday, there is going to be big trouble from this. *BIG* trouble.

You heard it from me first.

You might ask "Perry, what could possibly satisfy your perfectionistic
criteria?" Well, a language that didn't have any I/O or similar
"dangerous" capabilities in it at all, rather than one in which such
capabilities were selectively "restricted", would be one I would feel
much more comfortable trusting. If written in a fairly safe language
where it is hard to pull buffer overflow tricks, the interpreter for
such a language would be very hard to pervert into doing untoward
things. Java isn't like that, though. Its got the full power and glory
of any other language, and the only thing sitting between a HotJava
app and some really nasty viral effect is a paper thin shield -- the
security model. A couple of bits twiddled in the right place and the
shield is gone.

The best things about Java could probably have been achieved without
giving it so much power. Its too late now, though. The bandwagon is
too far along. As a security consultant, I'm of course in a position
to profit from the wreckage, but frankly I don't like that any more
than an aircraft disaster expert wants to see more aircraft accidents.


Perry

On Sun, 8 Oct 1995, Perry E. Metzger wrote:

> 
> As long as people are mentioning Java, I just want to make the
> prediction, one more time, that at some point someone is going to find
> some devistating security holes in HotJava.

	I'd like to make this prediction:  someone at some point in time 
will find another serious security hole in SendMail.

	What you need to ask yourself is "Do the benefits of Java 
outweigh the security risks?"

greg.miller@shivasys.com
http://www.ius.indiana.edu/~gmiller/

Greg Miller writes:
> 
> On Sun, 8 Oct 1995, Perry E. Metzger wrote:
> 
> > 
> > As long as people are mentioning Java, I just want to make the
> > prediction, one more time, that at some point someone is going to find
> > some devistating security holes in HotJava.
> 
> 	I'd like to make this prediction:  someone at some point in time 
> will find another serious security hole in SendMail.

And yet again, my clients will be largely safe because I've dealt, in
advance, with most of the possible threats from Sendmail. I can't do
that for Java. I will never be able to do that for Java. I don't think
you understand the problem here at all.

> 	What you need to ask yourself is "Do the benefits of Java 
> outweigh the security risks?"

And the answer, to me, is "no". Unfortunately, I can't stop it.

Perry

| 	I'd like to make this prediction:  someone at some point in time 
| will find another serious security hole in SendMail.
| 
| 	What you need to ask yourself is "Do the benefits of Java 
| outweigh the security risks?"

	A substantial risk that Java carries is that its 'secure'
label will get in through doors which should have remained closed to
it.  I would be worried about Java capable browsers in the Federal
Reserve, because people will say 'its nifty, its labeled secure, lets
use it.'

	I think there are some interesting liability models waiting to
be explored here.

Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

Well those concerns are all fine and swell, but the same kind
of reasoning applies to any network application. There are buffer overflow
bugs in almost every web browser, there are overflow bugs in CERN HTTPD3.0,
and who knows, there are probably bugs in ELM/PINE. Millions of people
download software from the internet without seeing the source code
everyday and risk getting hit by trojan horses and viruses. People
make all kinds of transactions everyday where they rely on nothing more
than trust. (and a future tit-for-tat legal suit if possible) I am of
the opinion that risk is good. Java will not be perfect. There will
be holes, I'm sure of it. And each generation of web languages will be
more efficient and more secure, but none will ever be perfect. It's all
part of evolution. It's a problem that will be researched and
improved on, but you've got to break some eggs to make a cake
somewhere. 

  And the situation without Java is not much better. Most of Java 
functionality is faked with CGI scripts, usually written in perl,
and there are plenty of ways to screw up a CGI implementation to allow
holes.

  As I mentioned before, Java file i/o is not built into the language.
It is provided through a Java class you can use that implements native C code
methods. This is where the write restrictions are handled. All that is
needed to remove the ability to do file i/o is to delete this class
from your installation. It's like having C, but no standard library.

  Java is mostly a risk to consumers (the users with the browsers), and
not corporate networks who are running servers, *unless* the employees
are using Java on the firewalled network. 

  Java is a lot better than the situation with microsoft network, whereby
a user can send you a 386 executable, and it shows up with an icon
saying "click me" on your desktop, and clicking on it will run it.

-Ray

Ray Cromwell writes:
>   Well those concerns are all fine and swell, but the same kind
> of reasoning applies to any network application. There are buffer overflow
> bugs in almost every web browser, there are overflow bugs in CERN HTTPD3.0,
> and who knows, there are probably bugs in ELM/PINE.

I believe that the security related ones in those applications are
well within human ability to fix -- simply implementing some hygenic
coding practices stops them. I don't believe that is the case with
Java implementations. I don't know how I'd manage to produce a "safe"
Java. Its a neat programming language, by the way -- its only when you
rig yourself to automatically run code produce by hostile people that
the issue comes up.

>   And the situation without Java is not much better. Most of Java 
> functionality is faked with CGI scripts, usually written in perl,
> and there are plenty of ways to screw up a CGI implementation to allow
> holes.

Thats true, but again, there is the alternative of gaining the
functionality with truly safe languages.

>   Java is mostly a risk to consumers (the users with the browsers), and
> not corporate networks who are running servers, *unless* the employees
> are using Java on the firewalled network. 

Unfortunately, it will be very hard to stop people from doing just
that.

Perry

Perry - 
  This has come up several times on the java list; some of them are 
covered in the papers on java security, but there's no reason to believe 
that the treatment in those papers is necessarily correct. Given the fact 
that it has proved possible to core-dump the jvm interpreter in the 
past, it's possible there may be security leaks in the implementations out 
there. 

If anybody is going to perform a more rigorous evaluation of the both the 
theoretical security model, and of the re-ified systems curently extant, 
looking at java the language is not the best place to start. A much 
better place to start is to look at the class loader and the java VM

The major assumptions needed to allow for security are:

	1. It's impossible to upwards modify the JVM  call stack.
	2. It's impossible to construct a pointer to an object except via 
	   controlled calls to the JVM
	3. It's impossible to store a value of one type and access it as 
	   another.
	4. It's impossible to access non-public fields of an object

I'm not sure if these are sufficient; however they do present the most 
promising candidates for attacks. 

If 1 is false, then it becomes possible for a remote class to pretend 
to be a local class, and thus gain access to the file and networked classes.

If 2 is false, then the method gains un-restricted access to memory.
3 is similar to 2 - if you can turn an int into a pointer, you've won.

4 is imporant for many reasons - one obvious use is to change the the 
class-loader in a remote class to disguise it's origin, with the same 
result as 1. 

Any attack on the Java VM should start with the verifier in the 
class-loader. This is supposed to prevent 2 & 3. One of the sun papers 
refers to the verifier as a theorem prover- to me this implies that the 
design has been formally verfied, but then we know how much that's worth, 
don't we Phil :-)

BTW, source code for the Java VM is available for no cost; you just need 
to send in a request to the java team, and a notarised affidavit 
affirming that X sucks and NEWS was infinitely cooler.

See the java pages for more info  (http://java.sun.com/)

Simon
p.s.
	Strange fact: There's a reference to one of Allan Schiffman's papers 
in the first Java security paper's bibliography. The paper has nothing to do 
with S-HTTP or any other aspect of security. There also doesn't seem to 
be any actual cite in the paper itself. Go Fig...