Re: java security concerns
Sendmail is about 29K lines of C code -- not significantly larger by my standards -- and has proven nearly impossible to secure.
Good point.
Sendmail performs a much simpler task and has not proven secure.
I don't necessarily agree. The core java interpreter is simply: while (1) { get_next_opcode switch(x) { } }
... 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.
Its a useful metric. But the concept of trust isn't defined. If you write in pure Java code (that is no references to any native methods) we should be able to do much better than that. And since Java doesn't have "programs" it just has "classes" and many of those fit on two pages where does that leave us? Would it be reasonable to say that if I want to write a Java class I trust I should keep it under two pages? If I then write another class that uses that class, that is also under two pages have I met the requirement? Can this aggreagate four page Java class be trusted?
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.
Many times.
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.
I agree.
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.
I don't think the lawyers would let us. Would anyone be interested in a Java daemon that one could send arbitrary classes to in an attempt to subvert the runtime? I once thought this would be a good way to give safe exposure to the system in general. You know sort of "here's a program that can feed classes to a Java runtime on a system which is known to have a file X on it. Try to return the contents of X." It probably wouldn't be to useful beyond that, and it would only validate the classes you have access to, not necessarily the full set in a release. (hence my not doing it given its utility only in testing the core runtime) --Chuck
Perry:
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.
Chuck:
I don't think the lawyers would let us.
This is a shame. What reason would they have for not letting you? It could well be a very good marketing move. Maybe your marketing dept can convince the legal dept.
Would anyone be interested in a Java daemon that one could send arbitrary classes to in an attempt to subvert the runtime? I once thought this would be a good way to give safe exposure to the system in general. You know sort of "here's a program that can feed classes to a Java runtime on a system which is known to have a file X on it. Try to return the contents of X."
It probably wouldn't be to useful beyond that, and it would only validate the classes you have access to, not necessarily the full set in a release. (hence my not doing it given its utility only in testing the core runtime)
That, and a cash reward for getting the contents would be even better. -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 The Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer@c2.org
I think to require formally proven implementation for something like Java is simply unreasonable. Even if it were possible. The whole computer market, and for that matter, most of the market as a whole, relies on "unproven" products. Most of what you buy and use is based on a notion of "quality" which is merely an inductive argument that the product had no problems in the past. Everytime you buy a piece of software and use it, you risk your security. Everytime you ftp something off the net and run it, you are taking that risk. How do you know MS Word doesn't have security holes or trojan horses built in, have you seen the source? Software always has bugs, holes, and security flaws. It always will. If we were to require each new generation of software to be "formally correct", software would never evolve. There is an important feedback process between customers, software companies, and even hackers, that drives software towards higher quality. Perfect software implementations proven correct by mathematics is a pipe dream. Maybe you can have higher confidence in small, simple software -- I've heard Negroponte expressing that nostalgia for the days of word processors that ran in 32k of ram, but frankly, I'm glad those days are gone. Will the IPv6 and IPSEC stack implementations be formally proven correct? Yes, it may be possible that exploiting holes in Java will be easier than those in sendmail, just as it is easier to exploit a hole in software on a networked machine rather than a non-networked one. But this can not be an argument against Java or its utility. The same arguments were raised when Postscript first came out, yet the huge benefits of postscript are obvious, while the amount of security damage done by it is minimal. Java will have lots of holes. It will go through the same evolutionary progress that all software does. Sendmail was given a chance to evolve, I think Java deserves the same chance, given its potential. -Ray
I think to require formally proven implementation for something like Java is simply unreasonable. Even if it were possible. The whole computer market, and for that matter, most of the market as a whole, relies on "unproven" products. Most of what you buy and use is based on a notion of "quality" which is merely an inductive argument that the product had no problems in the past. Everytime you buy a piece of software and use it, you risk your security. Everytime you ftp something off the net and run it, you are taking that risk. How do you know MS Word doesn't have security holes or trojan horses built in, have you seen the source? Software always has bugs, holes, and security flaws. It always will. If we were to require each new generation of software to be "formally correct", software would never evolve. There is an important feedback process between customers, software companies, and even hackers, that drives software towards higher quality. Perfect software implementations proven correct by mathematics is a pipe dream. Maybe you can have higher confidence in small, simple software -- I've heard Negroponte expressing that nostalgia for the days of word processors that ran in 32k of ram, but frankly, I'm glad those days are gone.
What you miss is the distinction between different kinds of programs and their protection implications. Networking programs with unintended flaws may allow outsiders to gain access to your internal network and do harm. Non-networking programs with unintended flaws may fail to operate properly or act as a vector for the spread of corruption, but they don't give outsiders unlimited insider access without insiders somehow facilitating the process. That's why we are far more concerned about networking programs that about word processors. In terms of word processors with Trojan horses, we don't want them either, but there's a big difference between a Trojan horse and the ability to spread a virus. Viruses can spread whenever there is sharing and general purpose programming. Hence, most modern spreadsheets, word processors, Postscript interpreters, etc. allow viruses to spread. A big problem with remote auto-execution is that it allows someone not authorized to use your computer decide to run a program on it. This may make you the unwhitting vector for a virus, cause your system to crash, etc. With auto-execution, the web turns from a networked read-only database with limited searching capabilities into a giant distributed processor in which the users have little or no control over what their computers are used for. The battle is for control over your own computer and what it does.
Will the IPv6 and IPSEC stack implementations be formally proven correct?
Yes, it may be possible that exploiting holes in Java will be easier than those in sendmail, just as it is easier to exploit a hole in software on a networked machine rather than a non-networked one. But this can not be an argument against Java or its utility. The same arguments were raised when Postscript first came out, yet the huge benefits of postscript are obvious, while the amount of security damage done by it is minimal. Java will have lots of holes. It will go through the same evolutionary progress that all software does. Sendmail was given a chance to evolve, I think Java deserves the same chance, given its potential.
I don't see any huge benefits to postscript. In fact, postscript files are essentially impossible to search for items of interest, to display on a normal video screen, to quote from without reentering the data, etc. The point is, do we want to turn the Web into a distributed computing environment in which anyone can eecute any code on anyone else's computers? Don't assume I am against it - after all, I was the only vocal proponent of viral computing for almost 5 years and got villafied for it plenty of times. I am in favor of making the decision conciously, not by accident or ignorance, and providing proper protection mechanisms. If the question of Hot Java is asked in terms of permitting all computers using the Web to become part of a global viral computing environment, I am ready to hear the answer. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
Ray Cromwell writes:
Yes, it may be possible that exploiting holes in Java will be easier than those in sendmail, just as it is easier to exploit a hole in software on a networked machine rather than a non-networked one. But this can not be an argument against Java or its utility. The same arguments were raised when Postscript first came out, yet the huge benefits of postscript are obvious, while the amount of security damage done by it is minimal.
Postscript is completely safe if the interpreter is emasculated, and most of them are. (It is a huge risk when run on a non-emasculated interpreter, but fortunately it is easy to castrate one of the things.) Java isn't like that, unfortunately. I wish it was simply a display-postscript like thing that built pretty pictures inside a confined window -- I could trust that to be done right if it was done carefully. Perry
Iam sorry I dont fallow your logic. You find Postscript files save because you can set up the interpreter to ignore Postscript commands to write to files and execute programms (check the CIAC alerts), yet you find Java applets insecure even when you can set up the same restrictions and more under HotJava (and hopefully Netscape)? That does not compute. Granted Java is certanly more complex than postscriptm it a genereric programming language, and will be used by more people. But that same concept aply. 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 Tue, 10 Oct 1995, Perry E. Metzger wrote:
Postscript is completely safe if the interpreter is emasculated, and most of them are. (It is a huge risk when run on a non-emasculated interpreter, but fortunately it is easy to castrate one of the things.)
Java isn't like that, unfortunately. I wish it was simply a display-postscript like thing that built pretty pictures inside a confined window -- I could trust that to be done right if it was done carefully.
Perry
Aleph One writes:
Iam sorry I dont fallow your logic. You find Postscript files save because you can set up the interpreter to ignore Postscript commands to write to files and execute programms (check the CIAC alerts), yet you find Java applets insecure even when you can set up the same restrictions and more under HotJava (and hopefully Netscape)? That does not compute.
Yes it does. To (perhaps over)simplify my point, the Java interpreter cannot be stripped of all i/o capabilities and still remain useful. I can physically remove all the "dangerous" calls from a Postscript interpreter and still have it be useful. Perry
Aleph One writes:
Iam sorry I dont fallow your logic. You find Postscript files save because you can set up the interpreter to ignore Postscript commands to write to files and execute programms (check the CIAC alerts), yet you find Java applets insecure even when you can set up the same restrictions and more under HotJava (and hopefully Netscape)? That does not compute.
Yes it does.
To (perhaps over)simplify my point, the Java interpreter cannot be stripped of all i/o capabilities and still remain useful. I can physically remove all the "dangerous" calls from a Postscript interpreter and still have it be useful.
There is a large class of Java apps that need no file i/o capability. 99% of all Java apps on the web right now don't save any persistent state information. I couldn't find any Java apps on the Java page that used file i/o. If by "stripped of i/o capabilities", you mean that the Java interpreter is not permitted to ever call open/read/write, not even to read in files it needs like config/preferences files or dynamically linked libraries, I'd say that's absurd. There's not many things that can be stripped of such capabilities, including postscript interpreters, except for those which run the interpreter straight out of rom. But it's still unclear whether those lack "i/o capabilities", given that some postscript printers run operating systems and tcp/ip stacks, and it is feasible for the interpreter to crash and execute an i/o call. However, the Java interpreter can certainly be compiled to not allow Java applets to ever do disk or network i/o. It doesn't even take a recompile. Just delete the file i/o class. It is certainly possible, to within a high degree of confidence, to "box in" all i/o calls, especially if they are run in a separate process. -Ray
Perry E. Metzger writes:
To (perhaps over)simplify my point, the Java interpreter cannot be stripped of all i/o capabilities and still remain useful.
?!? What if all I give you is a couple of Java classes that write to a frame buffer, and that frame buffer is the screen (or your 24-pin dot matrix printer or whatever)?
I can physically remove all the "dangerous" calls from a Postscript interpreter and still have it be useful.
I don't see the difference. An interpreter is an interpreter. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) | | stand there and flap your arms like a fish. | Tivoli Systems, Austin TX | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike McNally writes:
I can physically remove all the "dangerous" calls from a Postscript interpreter and still have it be useful.
I don't see the difference. An interpreter is an interpreter.
I suppose most of this is dead obvious to me because I work in security every day, but it seems that some otherwise smart people don't see the point I'm making, repeatedly. As an exercise to the reader compare the following two tasks in difficulty. 1) Find a bug that lets you execute arbitrary programs unintentionally from a program that contains instances of the 'fork()' system call. 2) Find a bug that lets you execute arbitrary programs unintentionally from a program that contains *no* instances of the 'fork()' system call. [hint: it is much harder to get a program to do something that it has no code at all to do than to get it to do a buggy form of a something it already does.] Perry
Mike McNally writes:
I can physically remove all the "dangerous" calls from a Postscript interpreter and still have it be useful.
I don't see the difference. An interpreter is an interpreter.
I suppose most of this is dead obvious to me because I work in security every day, but it seems that some otherwise smart people don't see the point I'm making, repeatedly.
As an exercise to the reader compare the following two tasks in difficulty.
1) Find a bug that lets you execute arbitrary programs unintentionally from a program that contains instances of the 'fork()' system call.
2) Find a bug that lets you execute arbitrary programs unintentionally from a program that contains *no* instances of the 'fork()' system call.
I agree, however I would point out that not all postscript interpreters are emasculated (especially those on unix systems like IRIX, they contain all kinds of calls to fork(), read()/open(), etc). Nothing in the Java spec tells you that you must call fork() in a Java interpreter implementation. In fact, Java has nothing to do with the GUI calls, the network calls, etc. You can support as much or as little system I/O in a Java implementation as you want. If need be, a Java implementation could hard code all data needed from a hard disk into executable and run entirely in ram, and totally remove all file system access. (except the implicit one needed to load and run the executable in the first place) Even Java apps without network or filesystem capability are useful (as graphic widgets), but I think atleast the ability to load URLs is a good thing, and can be done in a reasonable secure manner. Atleast from my reading of the Java Language Spec, and Virtual Machine, there is no requirement that an implementation implement the File I/O classes. Having a standardized class hierarchy is probably a good idea though. -Ray
Ray Cromwell writes:
I agree, however I would point out that not all postscript interpreters are emasculated (especially those on unix systems like IRIX, they contain all kinds of calls to fork(), read()/open(), etc).
Many postscript interpreters are a serious security threat. However, I found it fairly easy to chop enough of the code out for the one I run that I feel safe with it -- the exercise wasn't that hard.
Nothing in the Java spec tells you that you must call fork() in a Java interpreter implementation. In fact, Java has nothing to do with the GUI calls, the network calls, etc. You can support as much or as little system I/O in a Java implementation as you want.
Yes, but in practice, to support the given applets that Netscape will be browsing you have to open the kimono a bit too much overall. With sufficient emasculation, I believe Java could be made safe, but then it wouldn't be the Java that Sun and Netscape are pushing any more. Perry
Perry writes:
Ray Cromwell writes:
Yes, it may be possible that exploiting holes in Java will be easier than those in sendmail, just as it is easier to exploit a hole in software on a networked machine rather than a non-networked one. But this can not be an argument against Java or its utility. The same arguments were raised when Postscript first came out, yet the huge benefits of postscript are obvious, while the amount of security damage done by it is minimal.
Postscript is completely safe if the interpreter is emasculated, and most of them are. (It is a huge risk when run on a non-emasculated interpreter, but fortunately it is easy to castrate one of the things.)
I'm not clear on what you mean by emasculated. It seems to me that postscript interpreters are full of holes that can be exploited by a cleaver enough attacker. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236
On Mon, 09 Oct 1995 17:30:38 -0700, cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis) wrote:
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.
I don't think the lawyers would let us.
Pardon my French, but if your lawyers make it impossible to do technical work correctly, isn't it time to get new lawyers? I can't see how offering a reward for reporting bugs could possibly be objectionable to any rational lawyer. This can be a VERY useful (and very inexpensive) debugging technique. Didn't Knuth offer a cash reward to the first person to find each typo in his "Fundamental Algorithms" series -- and then doubled the amount each year? It can also be a very useful teaching tool, in that it encourages users to explore little-used corners of a system. I applaud any company that has the guts to do it.
On Tue, 10 Oct 1995, John Lull wrote:
On Mon, 09 Oct 1995 17:30:38 -0700, cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis) wrote:
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.
I don't think the lawyers would let us. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think this means they didn't ask. If they did, perhaps the problem is their ability to say with a straight face that their product is "secure" while at the same time running a contest to find insecurities!
EBD
Pardon my French, but if your lawyers make it impossible to do technical work correctly, isn't it time to get new lawyers? I can't see how offering a reward for reporting bugs could possibly be objectionable to any rational lawyer.
This can be a VERY useful (and very inexpensive) debugging technique. Didn't Knuth offer a cash reward to the first person to find each typo in his "Fundamental Algorithms" series -- and then doubled the amount each year?
It can also be a very useful teaching tool, in that it encourages users to explore little-used corners of a system.
I applaud any company that has the guts to do it.
Not a lawyer on the Net, although I play one in real life. ********************************************************** Flame away! I get treated worse in person every day!!
On Tue, 10 Oct 1995, John Lull wrote:
Pardon my French, but if your lawyers make it impossible to do technical work correctly, isn't it time to get new lawyers? I can't see how offering a reward for reporting bugs could possibly be objectionable to any rational lawyer.
I agree; I sent private mail to the parties saying in effect "if your lawyer can't structure this, it's time to get a new lawyer." A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin@law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | New address, but it's still just as hot here.
participants (10)
-
Aleph One -
Brian Davis -
cmcmanis＠scndprsn.Eng.Sun.COM -
fc＠all.net -
John Lull -
m5＠dev.tivoli.com -
Michael Froomkin -
Perry E. Metzger -
Ray Cromwell -
sameer