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/
| 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
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
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...
participants (5)
-
Adam Shostack -
Greg Miller -
Perry E. Metzger -
Ray Cromwell -
Simon Spero