When they introduced the Java programming language last year, Sun Microsystems introduced a long list of Java buzzwords and made a number of claims about its safety and security. Their web page, "Frequently Asked Questions - Applet Security," gives a comprehensive list of activities that Java applets are supposedly not allowed to do. Already a number of their claims have been shown to be premature.
One has only to look at the recent paper of Princeton researchers Dean, Felten, and Wallach, "Java Security: From HotJava to Netscape and Beyond," to find a compendium of the hostile actions that Java applets can perform. This paper is neither melodramatic nor designed to induce panic; it is a factual account of what has already been done together with an understated assessment of the current state of Java Security and its future prospects. The main shortcoming of the paper, like so many other security analyses, is its lack of concrete examples. Without such examples to ponder, businessmen and information professionals may be forced to choose blindly between competing camps. When Sun and Princeton disagree, how are we to decide where truth lies? And if Sun and Princeton collaborate and reach a consensus, how are we to assess their conclusions?
When we hear talk of information warfare and read about the exploits of hackers, for better or worse our senses are titillated. While we seek protection, we often have a prurient interest in seeing the drama unfold. Now Java makes it a simple matter for anyone to become a hacker and information warrior. It takes a relatively short time to learn Java, and it takes very little effort to begin writing hostile applets. The implications for business on the Web are not encouraging.
A hostile applet is any applet which, when downloaded, attempts to monopolize or exploit your system's resources in an inappropriate manner. An applet which performs, or causes you to perform, an action which you would not otherwise care to do should be deemed hostile. Denial-of-service applets, mail forging applets, and applets which surreptitiously run other people's program on your workstation are all clear-cut examples of hostile applets. But the definition is problematic. Is an applet which annoys you, perhaps on account of some programming error, to be regarded as hostile? Is an applet hostile just because you don't approve of its effects? Have you tacitly consented to every possible effect by virtue of using a Java-enabled browser? These are just a few of the thorny issues waiting to be resolved.
The ongoing research at Princeton has shown the potentially deleterious effects of hostile applets. So far these applets have only appeared under controlled conditions and have not been set loose to wreak havoc on the Web. But applets need not seek the Hackers' Holy Grail of altering, reading, and deleting files in order to be hostile. Sometimes it can be advantageous just to exploit someone's resources silently, and at other times simply being annoying and disruptive can achieve some ends. These sorts of hostile applets do exist, are easily written, and are readily available on the Web. As will be seen shortly, they pose a serious threat to electronic commerce when clients' browsers are Java-enabled.
One collection of hostile applets, with freely available source code, has already appeared on the "Hostile Applets Home Page," and DigiCrime has promised that more are on the way. On the Hostile Applets Home Page you will find examples of applets which can:
Let's take a look at a hostile applet whose implications for business on the Web are clear. The Business Assassin applet targets the applets of a particular business by killing the threads in its main thread groups (and destroying those thread groups whenever possible). This particular applet has Gamelan as its target. If your business is in competition with Gamelan, and you place this applet on your web page, the person who views your page will find that the applets on Gamelan's home page will be unable to start. Additionally, uncommenting the last three lines of the source code and then re-compiling it again before deployment will cause the applet to unleash a withering "big windows" assault on the browser of the unfortunate person who visits Gamelan. It would also be very easy to have the applet pop up windows with disinformation whenever Gamelan is visited.
Like many other hostile applets, this one appears to be entirely inert. The real action takes place in threads. The Java programmer may initiate threads at will in an applet, but the language imposes no requirement that the threads be stopped when the browser leaves the web page. Thus threads may run in the browser as ghosts of departed applets. Hostile applets can take advantage of this capability by lingering for a specified amount before initiating some attack. In the present case, the Business Assasin applet exploits an apparent implementation bug in the Security Manager which is supposed to disallow it access to threads in other thread groups. It waits and watches for the thread groups and threads from Gamelan to appear, and it begins its attack when they do.
Hostile applets come in many different forms. Some, like the Noisy Bear who refuses to be quiet, are merely annoying. Others can consume your system resources to such an extent that your browser comes to a grinding halt. There are hostile applets which attack you with big windows and effectively exclude you from your computer. An applet can even spoof a security alert and seek a login and password, reporting any results back to its home host and then attacking you no matter what you do. Almost mercifully, there is even an applet which annihilates all other applets, but which averts suicide and can raise itself from the dead to haunt your browser (which we are tempted to call a "Disable Java" spoofing applet).
Of course hostile applets need not announce their presence so dramatically. Some of them would rather have their presence never be known. Any program that can be written in Java can be run in a thread in your browser, and Java allows an applet to stealthily connect to ports on the host from which it came. Thus it should be no surprise that there are sneaky applets which simply exploit your resources to run other people's programs and send them back the results - quite an asset if your a business or government with limited computational resources.
Yet other applets can play serious pranks on consumers. How would you like to have electronic mail submitted by an applet on your behalf? A mail forging applet can order lots of merchandise for you. It can send "your" secret opinion to any of the news groups, and it can threaten elected officials in your name. It can even occasionally exploit "sendmail" and discern your entire e-mail address (user name included) when you wanted your privacy protected.
It takes very little imagination to understand the threat of hostile applets to elctronic commerce on the World Wide Web. Indeed, simply knowing that there are dangerous applets out there would be enough to discourage some. A chance encounter with such a creature would be more than enough to make an impatient and demanding shopper go elsewhere to do business, and the prospect of being defenseless in the face of repeated random encounters with nasty applets would surely drive away droves of potential customers. Clearly then the time has come to face the problems posed by hostile applets and to start solving them.
When hostile applets leaped into Sun's Java security sandbox several months ago and began kicking sand in people's faces, they were dismissed by Aurthur van Hoff (in a note to comp.lang.java) as not a very serious problem which, at any rate, was Netscape's to solve. CERT was not the least bit concerned about stealthy resource-exploiting applets. One engineer at SUN was sent the source code for the applet which can get e-mail addresses but apparently failed to understand how it exploited "sendmail" to do so. We would hear time and again (and indeed we still do) about the difficulties of discerning an MPEG decoder from a hostile applet. Both the Java Developers Kit and Netscape have gone through several releases, and yet the problems posed by hostile applets remain.
While many computer security professionals were fascinated by what hostile applets can do (the usual repsonse being "Cool!"), until a recent report by OBC, the problems were mostly overlooked and ignored. Now the situation is starting to change. Sun has recently acknowledged that the problems are serious, and they "recognize the importance of providing people with some mechanism to deal with hostile applets." They are investigating "ways to better monitor and control the use (or abuse) of resources by Java classes." Enforcing certain resource limits is one idea, and providing the classes necessary to allow browsers to construct applet monitors is another. If successfully carried out, these ideas would go very far in the battle against denial-of-service applets.
But this does not begin to address the questions posed by the more stealthy members of the Hostile Applets Family. Even if all of the security bugs are eliminated, and if the rules allowing applets to connect only to ports on their home hosts are perfectly enforced, the fact remains that applets can do dangerous and illegal things. Applets that can connect to port 25 (smtp) and port 23 (telnet) can still pose security risks. And allowing applets to connect to ports on their home hosts still leaves your system vulnerable to having its resources exploited by unscrupulous persons for unknown ends. By viewing an applet you could still be helping a business competitor, a foreign government, or even a criminal organization. Clearly more precise monitoring of applets will be necessary to minimize the risks here, and it may be wiser to simply deny applets making network connections altogether.
Sad to say, we live in a very hostile world. Just as there are wicked people to be found in all walks of life, so are there hostile applets. From the initial media enthusiasm and the types of Java applets that were created and publicized, one easily gained the mistaken impression that all applets are friendly (or perhaps cool, cute, and silly). But given human nature, it was just a matter of time before the first hostile applets were created and deployed. If Java has been given a punch in the nose and a black eye by hostile applets, perhaps it was not undeserved. It is far better that it happen now, and it is far better that it happen in public. Having hostile applets freely available to the Web community to battle is a potential source of strength for the future of Java.
The problems with Java are not easily solvable, and they are certainly not going to go away in the near future. In that regard Java may be more akin to "sendmail" than to C++. At this point we should also point out that JavaScript poses almost as many problems as Java. In the future we expect there to be a closer interaction between Java and JavaScript, and this may pose whole new sets of risks. Until some solutions are available how should the Web community as a whole, and the business community in particular, respond? If one eschews the opinion of DigiCrime with regard to Java, "Be afraid. Be very afraid," then perhaps a paraphrase will do: "Be cautious. Be very cautious."