java security concerns

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

Chuck McManis writes:
> 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.

Sendmail is about 29K lines of C code -- not significantly larger by
my standards -- and has proven nearly impossible to secure.

> 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.

Sendmail performs a much simpler task and has not proven secure.

Look, I'm not arguing that you and the rest of the Java folks aren't
smart people who have worked very hard. I've got a great deal of
respect for Gosling and the rest of you guys. Unfortunately, you've
taken on an impossible task. Marcus Ranum has noted that you can't
trust a program thats bigger than a couple of pages long, and I
believe he's right. Thats why when there is a program that I
absolutely have to trust I make sure it isn't any longer than
that. (This is frequently a very practical thing, by the way.)

As an aside, have you tried breaking your own program? Spend a week on
it some time. Its usually an educational experience and it breaks you
out of the mindset you have fixed in for a while.

As people have found out, it has proven possible to core dump the Java
interpreter. That means that your implementation has contained flaws
that potentially permitted people to do unplanned things to the state
of the interpreter.

By the way, I suggest that Sun should offer a large money prize for
the first significant security hole found the Java implementation. Its
a tiny price to pay for security.

Perry

On Mon, 9 Oct 1995, Perry E. Metzger wrote:

[ I just got Man-On-The-Street'ed by a TV news crew asking my opinion of 
  the OJ Verdict, I'm entitled to a little Side-Bar 

> Sendmail is about 29K lines of C code -- not significantly larger by
> my standards -- and has proven nearly impossible to secure.

Hey - but sendmail was designed to be Z-1 secure - formally proven to be 
unsecurable :-)

> taken on an impossible task. Marcus Ranum has noted that you can't
> trust a program thats bigger than a couple of pages long, and I

For the general case this is true. To be able to trust larger systems, you
need to not only be able to trust the individual 2 pagers, but to also be
able to show that composing the sub units doesn't lose whatever property
you're trying to do. The architecture of the system needs to be designed
with this in mind; otherwise reasoning about the composite becomes
intractable. There are all sorts of things you can do to make analysis
easier - eliminating global state, etc. Retrofitting security or 
verifiability never works. 

Distributed co-operative theorem proving, anyone?

END-DIGRESSION]

Real point of the message:

In my previous message, I left out some fundamental parts of the run-time 
that need to be looked at carefully. The garbage collection needs to be 
examined carefully. Normally GC algorithms are formally derived, so it's 
the implementation that needs to be checked for. holes in the GC may be 
too unpredictable to exploit for anything but core-dumping, especially since 
java uses a mark-sweep conservative collector. 

A more promising area of attack might be the Thread system. If the thread
system can be confused, it might be possible to have an untrusted app
start executing in the context of a trusted thread. This may or may not 
be exploitable, depending on how much of the untrusted threads context 
gets held over (call stack, etc), but could be fun if it works.

Simon

> > taken on an impossible task. Marcus Ranum has noted that you can't
> > trust a program thats bigger than a couple of pages long, and I

Marcus agreed with a position founded on the work in the late 70s and
early 80s by many researchers on proving the security of operating
systems under the Bell-Lapadula model.  The main result I recall is that
a Cray-1 took 24 hours to prove the Simple Security Property about a
100-line limited-Pascal program used as the core of (I think it was)
UCLA-secure Unix.  Complexity goes up quickly with program size, and this
property is only one of many you might like to prove.

> For the general case this is true. To be able to trust larger systems, you
> need to not only be able to trust the individual 2 pagers, but to also be
> able to show that composing the sub units doesn't lose whatever property
> you're trying to do.
...
> Distributed co-operative theorem proving, anyone?

Let's go - I will provide the distribution mechanisms, and I think I
know someone who is interested in the theorem proof side.  I know of
several experts on theorum proving who may well pitch in.  What program
do you want to prove secure next (we're currently finishing up my secure
Web server).

...
> Real point of the message:
> 
> In my previous message, I left out some fundamental parts of the run-time 
> that need to be looked at carefully. The garbage collection needs to be 
> examined carefully. Normally GC algorithms are formally derived, so it's 
> the implementation that needs to be checked for. holes in the GC may be 
> too unpredictable to exploit for anything but core-dumping, especially since 
> java uses a mark-sweep conservative collector. 

The core dumping shows that Java can ALSO write files into the file
system, something it was claimed to NEVER be able to do! If you could
get the right name for the core file, and set up the first few bytes
right, ... 

> A more promising area of attack might be the Thread system. If the thread
> system can be confused, it might be possible to have an untrusted app
> start executing in the context of a trusted thread. This may or may not 
> be exploitable, depending on how much of the untrusted threads context 
> gets held over (call stack, etc), but could be fun if it works.

Why not start much simpler.  Write a Java program to disrupt services by
flooding the local network with garbage packets - or with some sort of
request it lets you write. How about a Java program that launches SATAN
probes against all reachable hosts?

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

Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 

On Mon, 9 Oct 1995, Dr. Frederick B. Cohen wrote:

> The core dumping shows that Java can ALSO write files into the file
> system, something it was claimed to NEVER be able to do! If you could
> get the right name for the core file, and set up the first few bytes
> right, ... 
> 

Please stop and go read the documentation and papers off sun's web site.
Who ever said that Java cant write to file are not in their right mind.
Those who belive it are more so. Java is a programming language. It can
certanly write to files. Now whatever an interpreter (in this case called
by HotJava or Netscape ) allows the application to do is another thing.
You can as well distribute binary C programms but before running them
try to examine it to see if access the filesystem. (You might even hack
your kernel or libraries to stop any process with certain flag from doing 
so). Java just makes this easier. You can even set up the HotJava browser 
to do no security check at all. All depends in the security model you choose.
Dito for net connections or anything else.

Now if all of you would please go use the product or learn more about it 
before bashing it I would not have to waste my time reaplying to this.

> Why not start much simpler.  Write a Java program to disrupt services by
> flooding the local network with garbage packets - or with some sort of
> request it lets you write. How about a Java program that launches SATAN
> probes against all reachable hosts?
> 

See about. Read the hotjava man page.

Dr. Frederick B. Cohen wrote:

| > For the general case this is true. To be able to trust larger systems, you
| > need to not only be able to trust the individual 2 pagers, but to also be
| > able to show that composing the sub units doesn't lose whatever property
| > you're trying to do.
| ...
| > Distributed co-operative theorem proving, anyone?
| 
| Let's go - I will provide the distribution mechanisms, and I think I
| know someone who is interested in the theorem proof side.  I know of
| several experts on theorum proving who may well pitch in.  What program
| do you want to prove secure next (we're currently finishing up my secure
| Web server).

	I'd be real intereseted in seeing an MTA proven secure.  Smail
or Zmailer perhaps?

Adam


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

...
> 	I'd be real intereseted in seeing an MTA proven secure.  Smail
> or Zmailer perhaps?

The problem is that such programs were not designed to be secure (as far
as I am aware) or to be proven secure, and thus, even with lots of
computing power, there is essentially no hope of doing this.  In fact,
they are almost certainly not secure (as these proofs generally help detect).

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