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
participants (6)
-
Adam Shostack -
Aleph One -
cmcmanis＠scndprsn.Eng.Sun.COM -
fc＠all.net -
Perry E. Metzger -
Simon Spero