|> As a security consultant, I'm very happy about Java because once the |> holes are found in it and massive, Morris style worms are launched |> with it, I'll be laughing all the way to the bank. |> I exagerate only slightly. I don't believe Java to be secure, in spite |> of the claims. Its too complicated, and it operates in an environment |> who's correct operation is required for it to remain secure. Good |> system design says that you want a system's failure mode to produce a |> secure result, but thats not what Java does. I disagree for the simple reason that Java and Hotjava are not being treated as trusted code in their applications. Applets are tightly contrained in what they can do, and hotjava's default attempt to configure a "firewall" when it boots up is not likely to engender a false sense of security. I've been looking at the Java code closely for a couple of months now, and I find it to be relatively clean in its implementation (Solaris version at least). I think the biggest worry might be holes in the non-Sun ports along the host machine interfaces. Overall, I give the Solaris implementation extremelly high marks in terms of its security. I think I'm actually more worried by far less powerful browsers whose code I don't approve of, like Mosaic. The vast majority of security problems result from the fact that most code has security added in AFTER coding starts. Java has been designed for excellent security from the very begining. JWS

Thus spake Perry: |> solman@MIT.EDU writes: |> > I disagree for the simple reason that Java and Hotjava are not being |> > treated as trusted code in their applications. Applets are tightly |> > contrained in what they can do, |> You are incorrect. Applets are DESIGNED to be tightly constrained in |> what they do. You want to bet your career that there are no bugs in |> the implementation of this design? The thing keeping you from opening |> sockets or doing file-io is a very thin scrim. Are you *certain* that |> it is bug free? I'm not. What's with the facetious questions? Only an idiot would guarantee a piece of software to be error free. I am highly confident that there is very little probability of a raider applet doing significant damage. That's as much as I can say of any of of any of the systems I use... and its saying alot given that the thing is executing code it pulls off the net. Is there still room for cleaner code? Definitely, and I think we'll see some of it as Java goes Beta and then production. |> I like systems that are more fail-safe. About half a dozen |> simultaneous bugs would be needed to break some of my more secure |> firewalls, for example. Java does *not* provide security in depth. I think that the high level architecture of Java provides as much security as such a product can possibly provide. By the time Java becomes widely distributed (it is still in Alpha3), I expect it to have features that deny access to any applet not signed by somebody in a list the user creates, a sort of web of trust. On top of this layer, Java already offers rudimentary firewalls. The combination of these layers should be quite effective. Of course, Netscape will probably find a way to screw their implementation up :) JWS

Ray Cromwell writes:

...

Just a quick note to chime in. The OSF just did a deal with Sun to port Java to several platforms. The OSF is opening a "web mall" where you can grab software objects and run them. Expect to Java *really* take off in about 2-3 months. Every business on the net is going to want a Java shopping-client-basket on their web-mall/web-store. (Web Consultants! Learn Java!)

As a security consultant, I'm very happy about Java because once the holes are found in it and massive, Morris style worms are launched with it, I'll be laughing all the way to the bank.

Holes have already been found in CERN HTTP. The GETS() style bug was in the first few versions allowing attacks to overwrite the process stack. Any mail server written in perl is susceptible to weird attacks. For instance, if you ever eval/exec any variable that is double-quoted, rather than single quoted, it is possible to run shell commands via backtics or shell subprocesses in variable names. In fact, can you even prove that elm or pine don't have some obscure bug wherein a certain message, say with malformed headers, can overwrite the stack and allow Morris style attacks? The "Good Times" virus may actually be possible. Security is very nice to have. it's nice to rely on. But sometimes there's a need for some liberty. Make everything as secure as you can, but if security prevents you from doing something that you want to do, it's not helping you. The internet would be a very cold and barren place if the only application people ran was mail. Object Oriented Superdistributed components are so useful an abstraction, I think it's worth the security risk. HotJava solves some fundamental issues with protocols. Right now the W^3 working groups have been struggling to define URI/URCs and a whole host of other web protocols. They've been doing it for years, but they suffer from Xanadu like problems as far as I can tell. They don't want to saddle the web with a bad protocol, so they search to define a perfect one. Hence, no prototypes are ever deployed, because if they were, the user community might make them a defacto standard and lock them into it much like MS-DOS locked PCs into the Dark Ages. With Java, you define all the protocols you want. If your browser doesn't understand how to fetch a protocol, it can fetch a protocol handler. There's no need for a kitchen sink application that understands every protocol in existence. And with HotJava, you don't NEED to automatically fetch an application and run it. You can just use it as an extension language. If someone defines a new application or protocol handler for it, and this person is fairly trusted on the net, you can decide to run it (kinda like turning off autoload images), and even review the source code first. This is no less secure than ftping software from some site and compiling it. Maybe for you, the issue is protecting corporate networks behind firewalls. That's good, well then don't let employees run HotJava. However, I look at it from the home slip/ppp'ed user standpoint. I think over the next two years, slip/ppp'ed users will displace corporate/academic users as the largest group on the net. There will be worms and viruses. Just like there are nowadays. And there will be fixes. And there will be yet another arms race between virus writers and people who write anti-virus software. No doubt, there will be HotJava based worm/virus scanners, etc. A new market will come into being. You'll make money off of fixing holes. I'll make money off custom java clients business web pages. It's the price that should be paid, that is always paid, with any new technology. I'm not advocating being careless. I'm just saying that paranoid security hampers development of more robust and better software. HotJava is a piece of low-hanging fruit. As more people use it and more problems are found, better fruit will be found. -Ray

I suspect that the java-like methodology of downloading small apps to users can be done securely, but the java model doesn't feel like the right way to do it, at least to me.

I agree with you. However, I think the only way to get a handle on what the security issues are of such a methodology, is to deploy one and see what happens. Then you can build a second generation environment based on that knowledge. There's also the issue that even if the environment is secure on paper, with an application as large as a browser and an execution environment, you can never know if it was implemented properly. Sendmail-like bugs could haunt the system for years. That's why its good to deploy it early, fix all the big holes discovered as fast as possible. At minimum though, I think Java should atleast run chroot()ed on Unix systems. Instead, their approach is to define a "writable" directory on disk that apps can write too. This does make me nervous because I can see the potential to send over a program to be compiled and executed. I don't know what you would do under the MacOS and Win95 to make it secure. There is also security at the meta-applet level. Even if you chroot() Java to some directory where applets can write to, one applet can destroy another's data. If the data saved by one applet is valuable to you, like hotlist settings gathered over months, a rogue applet can trash them. But sometimes applets need to be able to read/write each others data so you can't just disallow it. So HotJava should have a access protocol for applets too. The Java team could learn a lot from the experience LambdaMOO. -Ray

Adam Shostack writes:

If I were running Java at home, I'd be a lot less worried, especially as all the interesting data on my hard drive sits on an encrypted partition.

Not everyone is so careful. To most people, their personal financial information, especially if it allows embezzlement from their accounts, is probably as valuable to them as a banks's information is to them... .pm

Ray wrote, responding to me: | > I suspect Ray is working in an environment less security | > concious than Perry's. Perry works on a lot of security-critical | > applications where a lot of money is at stake. If I were going to go | > after financial institutions, I'd definetly look at which ones were | > using Java, and see what I could upload into their systems. Getting | > copies of the recent files might be *very* informative. I'd be | > worried if I were at Solomon brothers. | If a business wants high security, they probably shouldn't be running | anything but mail. Even allowing users ftp access is dangerous | because someone could download a trojan horse. My college took | the /exec function out of IRC for this very reason. If data can | get through a firewall by any means, DNS, mail, etc, it's possible to write | some kind of program to send stolen information on those channels. Hell, | there is a big enough problem with users bringing software from home | into work and infecting company networks with viruses. FTP is available by mail. So is web access. Marcus Ranum (formerly of TIS) has written a TCP/IP over SMTP. (He doesn't distribute it.) The problem of securing a network in this environment is a very difficult one. Parts of it can be shown to be hard, although partial solutions are possible. I suspect the risks are enhanced by easy to use clients, as is the productivity of the workers. Many experts recommend studying each service and deciding whether or not to allow it based on a risk assesment. The size of Java makes it tough to evaluate, as does its extensible nature. I'm tempted to agree with Perry that its too big and doesn't have enough fail-safes yet. I'd be much happier if the Java execution environment did a chroot() before running any code, and code went to the executor through a one way funnel. Making this funnel truely one way limits the nifty things you can do with Java substantially. | Once you actually browse some HotJava web pages with HotJava, the | ordinary Web becomes static and boring. It's like the difference between | ftp and Netscape, or TinyMUD and LambdaMOO. There's just so much | potential, especially for crypto-clients. Because Java provides a | single development platform, single execution environment, GUI, and | network access. No argument here. I think Java is way nifty, and might be enough of a killer app for me to upgrade to a powerPC mac. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume

Phil Fraering writes:

How would you make Java secure or create a secure Javalike language? (Secure to your satisfaction, of course).

Well, you can't make anything secure, but you can make things more secure. My fundamentnal design principles are: 1) You can't abuse features you don't have. 2) You can't abuse privs you don't have. 3) You can't catastrophically fail to do something you don't do. I would eliminate the notion of having the Java interpreter make the system "safe" with language features that cripple certain threads of execution. Instead, I'd emasculate the whole system. Remove any i/o features right out of the interpreter -- ditto execution features or other features. I'd run the interpreter in a separate unix process communicating only through two pipes, one down which you feed code and mouse events and one up which you get bitmaps and URLs to fetch. The interpreter runs in a padded cell and can't alter the world except by passing up bitmaps and URLs. It doesn't talk to anything other than the browser. Even then, I'm not entirely comfortable, but I'm more comfortable.

What sort of interface does it have to the filesystem? I would guess that a secure language would have its own filesystem mapped to a file of fixed size in the normal filesystem, so that it couldn't cause disaster by filling your hard disk.

Thats not a secure system, because you depend on the interpreter properly doing the mapping. If there are no system calls to open(2) in the whole program it can't misuse any of those calls. If there are no calls to exec, it can't mis-execute things. Security through emasculation. Perry