In retrospect, 1996 has been a quite a year for Java Security holes. A year ago, when Java was first gaining notoriety, few people imagined that so many serious flaws would surface so quickly. In February a team of Princeton researchers demonstrated a DNS attack scenario under which untrusted Java applets could make arbitrary network connections. In March an Oxford researcher discovered a bug in the Java class loader, and the Princeton team revealed a serious flaw in the bytecode verifier. Untrusted applets exploiting either of these security holes could execute arbitrary machine code. Although these problems were immediately addressed by Sun Microsystems and Netscape Communications Corporation, subsequent releases of both Java and the Navigator proved vulnerable to similar attacks from Princeton and Oxford in May and June, and both had to be patched yet again. In August the Princeton team revealed how Microsoft's Internet Explorer 3.0 suffered from a number of similar problems. It is important to note that all of the offending applets were developed and tested by researchers, that they were never publicly released or observed, and that the flaws they revealed seem to have been corrected.
But March and April also saw the birth of a comprehensive collection of increasingly hostile Java applets. A hostile applet is any applet which, when downloaded, attempts to monopolize or exploit your system's resources in an inappropriate manner. Any applet which performs, or induces you to perform, an action which you would not otherwise care to perform should be regarded as hostile. The applets developed by the Princeton and Oxford researchers were certainly hostile, but applets need not read, alter, and delete files in order to be evil. 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.
The Hostile Applets Home Page provides information and examples of Java applets (with complete source code) which can:
As a result, in May Sun publicly acknowledged that the threats posed by hostile applets are serious. (For more details, see their FAQ web page.) They now "recognize the importance of providing people with some mechanism to deal with hostile applets," and they are investigating "ways to better monitor and control the use (or abuse) of resources by Java classes." So far, however, it appears that only the applet-killing applet has been defeated. Like its Ivy League cousins, the Applet Killer exploited an implementation bug (in a security check for thread access in this case), and correction of the bug rendered it harmless. Denial-of-service applets, stealthy applets, and social engineering applets will be much more difficult, if not impossible, to eliminate because they use only the most basic features of the Java language.
While the number and nature of security holes in Java might be frightening to some, they come as no surprise to computer security professionals and hackers. Any tool as complex and as powerful as Java, being a product of human ingenuity, is bound to have numerous errors in both concept and implementation. Inevitably, those errors are going to lead to serious security breaches, and some will only be corrected after damage has been done. Instead of trumpeting a long list of buzzwords and pretending to perfect security (as they did in their initial Java fanfare), Sun is is right to promote their "sandbox model" for Java Security. Whether that model is, in fact, adequate remains to be seen, but many of its ideas are sound.
The upcoming 1.1 release of the Java Development Kit (JDK) promises many new and exciting features. Although every new feature can be a potential source of security holes, the following seem almost certain to be so:
While it is true that users are usually the weakest link in system security, vendors often do a poor job of teaching them about how to use security features. Moreover, hardware and software vendors often ship products with important security features disabled. A telling example of this is OpenBoot, the firmware in the boot PROM on Sun workstations. By default its "security-mode" parameter is set to "none." By typing "Stop-a" one with no user account or priveleges can access the built-in Forth monitor and can, for instance, set NVRAM parameters, an act which requires root access from within Solaris to run the "eeprom" command. A skillful Forth programmer could access file systems, while a crude hacker could hijack the machine by booting from a CD-ROM. A more pertinent example is furnished by Netscape's Navigator. While many important security features are present, by default both Java and JavaScript are enabled, and no alerts will be shown before so-called "magic cookies" are written. Users may never become aware of any risks that this entails, and so they are left with defenses down in the face of programmed threats.
Additionally, documentation about security features is frequently sparse and misleading, difficult to locate, or non-existent. The thousands of pages of Java API documentation are a case in point. While one can find a brief glimpse of every method, constructor, and field of every class, exception, and interface in each package, one can search far and wide and not find a single example of how to write a secure ClassLoader or SecurityManager. Searching the published literature turns up little more than the usual platitudes about Java security and a few toy examples. It seems that the only publicly available example exists in the source code for the JDK, which must be obtained by license from Sun. Without more concrete security documentation, it is likely that application programmmers will have trouble implementing the security features that Java already provides.
From these considerations a framework for understanding Java Insecurity begins to emerge. The sheer complexity of the Java API virtually guarantees that flawed implementations and unexpected interactions between components will leave security holes to be discovered and exploited. This complexity also entails that application programmers can overlook or omit significant security features. The power of the language and ease of programming make exploiting security failures and finding unexpectedly hostile possibilities a much easier task. Moreover, a general lack of security awareness allows users, including system administrators, to become victims of a powerful new technology. Thus it seems likely that Java security problems will continue to multiply. In this respect Java should be likened more to sendmail than to C++.
While it is generally recognized that hostile applets present a threat to those browsing the World Wide Web, the dangers of Java applications have received much less attention. But the Java programming language gives hackers a powerful new set of tools, and it is only a matter of time before those tools will be used for evil purposes. Those who employ Java for network applications should be aware of the dangers that their applications may pose to their own systems. Perhaps nothing will illustrate these points better than a few choice examples.
Netcat is an incredibly simple, yet powerful, UNIX utility which can read and write data over networks using the TCP or UDP protocols. Among its many capabilities is port-scanning, the act of probing networks for potentially vulnerable services. Using Java it is a simple matter for any user to run an application which creates a ServerSocket that binds to a port and listens for inbound connections. But let the user beware. Tools like netcat can be used to find, attack, and overpower even sophisticated network applications. As a simple test the author set up a typical ServerSocket application and used netcat first to locate and then to hose it. Users who set up network applications, for whatever reasons, should be prepared to handle such assaults and attempted break-ins. In this case it was a naive Java application that fell prey to a non-Java tool, but a utility like netcat could readily be written in Java and deployed for information warfare.
Among Sun's most interesting new offerings is its Jeeves server software. The Alpha 2 release of Jeeves for Solaris is available via anonymous ftp from java.sun.com. Remarkably, it seems that anyone in the world can bypass any export controls and obtain the domestic U.S. version of Jeeves directly from Sun. To do so, one simply has to login anonymously, ignore the warning banner stating that anonymous ftp is no longer supported at that site, and get the binary file /pub/java/jeeves/Jeeves-alpha2-solaris-dom.zip. Jeeves will be at your service in a flash - an amazing lack of security on the part of those whose business is security.
The author was able to unpack and set up Jeeves in a matter of minutes as a rival to the local web server, with no particular skill or root privileges being necessary thanks to the power of Java. With a little effort one can set up Jeeves to use the Secure Sockets Layer (SSL) for all transactions. Thus this portable Java application allows an ordinary user to set up a compact, easy-to-manage web server right under anyone's nose. The opportunities for hackers and criminals to employ Jeeves as their servant seem endless. One has only to change the name of the Jeeves httpd to something innocuous like "emacs_macro" and bind to an obscure port to reduce the chances of detection. Doing so, one could easily advertise, borrowing the good name of a legitimate business and directing traffic to that obscure port. The ability to conduct secure transactions using SSL would certainly lend a convincing air to any criminal enterprise. Similar tactics could also be used by hackers or disgruntled users to embarrass an Internet service provider, perhaps putting it out of business. Here then is fine example of the power of Java turned to evil ends. Of course other tools could be used to do the same things, but once again Java makes it an easy matter to become a hacker and information warrior.
Recently Ed Felten and other members of the Safe Internet Programming team at Princeton demonstrated a novel "Web Spoofing" attack. In this attack a hostile web server lures victims to its site in order to position itself between them and the rest of the World Wide Web. Setting itself up as a "man in the middle," the hostile server can force hapless browsers to access all other web sites exclusively through itself. This allows the purveyor of the hostile server virtually unlimited possibilities to snoop on and tamper with its victims' transactions, including supposedly secure ones. While this attack seems unlikely to pose a serious threat, it remains possible and could still be successful because defeating it depends upon the vigilance of the user, still the weakest link in security. Once again Jeeves would make an excellent accomplice for the attacker. With a modest effort the attacker could incorporate the necessary URL rewriting scheme into Jeeves, thereby making Jeeves into the perfect tool to hijack a bona fide web site and carry out this web spoofing scam. These examples make it clear that the advent of Java has brought along many more risks than just those associated with executable content. As the Java Platform spreads to more machines and more users, so will the risks.
In March of 1996 the Symantec Corporation announced that SARC, its anti-virus research arm, was actively developing tools to handle possible viruses that could be transmitted by Java .class files, though no Java virus threats were known at that time. As they pointed out, a Java-based virus could take a variety of forms, and Java could then provide the vehicle for a virus to spread across a variety of platforms. Although PC viruses are well-known, there is a widely held myth that UNIX systems are somehow immune to viruses. Of course some of Fred Cohen's pioneering work on viruses was carried out on UNIX systems, and in the late 1980's Tom Duff and M. Douglas McIlroy developed several strains of UNIX viruses at AT&T Bell Laboratories. The possibility that hostile Java applications, once inadvertently trusted, could infect other Java programs must be entertained. While it would be relatively difficult to write such applications, their spread could be quite rapid due to the weakest links in security, system users. Moreover, Java applications can easily serve as the Trojan horses that can carry all sorts of viruses within their bellies.
In his well-known 1984 paper, "Reflections on Trusting Trust," Ken Thompson gave a simple example of a self-reproducing C program. As an argument in favor of the possibility of seeing Java platform viruses, the author wrote a simple self-reproducing Java application, Dupe.java. To test the application, one simply has to compile it with the command "javac Dupe.java," move the resulting file, Dupe.class, to a different directory (to avoid overwriting the original source code), and then run the application with the command "java Dupe." This generates a perfect copy of the source code directly from the class file. In this case we are fortunate that the program simply reproduces its source code and that its payload is just the silly assertion that "UNIX and Java viruses do not exist." It is a safe bet that in the future we will not continue to be so fortunate.
To illustrate the potential for Java applications to act as Trojan horses, the author first wrote a simple Bourne shell script virus which would work on almost any UNIX platform. The virus, homer.sh , echoes "Java is Safe, and UNIX viruses do not exist" and then proceeds to append a copy of itself to all non-infected Bourne shell scripts in the victim user's home directory. The author then wrote a little Java application, Homer.java , which, when inadvertently run by a user, generates a copy of homer.sh and executes it, thereby infecting the unfortunate user with a UNIX virus.
In order to assess the prospects for infecting a UNIX system with a virus by one means or another, the author took a survey of the "acme" system at the Georgia Institute of Technology using standard UNIX utilities. (This system is served by a SPARCcenter 2000, a SPARCserver 1000, and a SPARCstation 20.) The survey turned up a total of 1542 directories which had permmissions 777, of which 154 were home directories and 20 were users' "bin" directories; a total of 5849 files having permissions 666 under users' home directories; and a total of 5811 files having permissions 777 under users' home directories. Among the world-writeable directories, some were owned by privileged users and were most likely the remnants of system debugging and testing. Among the world-writeable files were dozens of ".login," ".profile," ".cshrc," and ".mailrc" files as well as hundreds of programs in various languages. Clearly many flavors of UNIX viruses could be introduced almost at will into this system. In a few years, assuming the acceptance and proliferation of the Java Platform around the globe, this system, and many others like it, could provide a ready home for countless Java-based viruses.
While Java security holes and hostile applets have received a great deal
of publicity in Java's first year, and rightly so, Java applications can
pose a much more profound threat to system security. The power and complexity
of the language make it extremely likely that security holes will continue
to appear in years to come. Java applications will also provide extremely
potent tools for hackers and information warriors, and any lack of security
awareness among those who write and use Java applications may translate into
security breaches. The cryptographic tools of the JavaSecurity API will
fail to protect users who either don't understand them or choose to ignore
them. It is entirely possible for Java to provide the mechanisms for
transmitting viruses, and the possibility of a Java Platform virus cannot
be dismissed out of hand.
References