A Collection of Increasingly Hostile Applets

These simple Java applets were created in order to point out the potential for downloading hostile applets. They weren't designed to be beautiful. Clearly there are many more effective ways that things can be done, and the presence of hostile activity need not be advertised at all. They've been tested on a Sun Sparcstation 20 running Solaris 2.5 and OpenWindows 3.5. They've also been tested on a DEC Alpha running Digital UNIX V3.2C and an SGI Indy running Irix 5.3. How effective they are depends on how you have things set up, so in any case you should exercise due caution in exploring their effects.

Sun's Java Web Server and IBM's WebSphere both offer a handy admin applet and admin servlet for web server administration. In our latest report we show how easy it is for an attacker to find an admin servlet and to launch a dictionary attack on the web server's administrator password by manipulating the admin servlet.

We recently examined Phaos Technology's SSLava Toolkit. What we found was quite a surprise. If you're in the market for such a toolkit, we recommend that you read our candid report before you buy.

There is a real need to scrutinize all types of Java-based products for security problems and to candidly report those problems in a public forum. This has the desirable dual effects of alerting users to threats and bringing market pressure to bear on vendors who continue to offer flawed products as secure solutions. In keeping with this line of thinking, we have recently taken a hard look at Sun's Java Wallet. This new group of hostile applets shows that they have a long way to go before they can claim to offer a secure electronic commerce product.

In my recently begun study of the various available Java decompilers, I decided that a fair test of their abilities would be to attempt to decompile all 1669 class files in the Netscape Communicator 4.04 distribution. I could not resist the temptation to inspect some of their output to see if I could turn up opportunities for hostile applets. Here are a few of the problems that I found. Like the original collection of hostile applets, these exhibit a range of unwelcome behavior - creating ClassLoaders (!), filling up your hard drive (!!), crashing the browser, hosing the Java audio player, forging theSystemPrincipal, and locating your plugins - not a very friendly collection of applets.

This latest article in the series examines Finjan's SurfinGate 2.0, SurfinCheck 1.0, and SurfinShield 2.0 for Windows NT. It illustrates just how easy it is to slip applets past SurfinGate, and it shows how to write applets which SurfinShield cannot stop.

This new article examines the products of several companies that market their Java-based software over the Internet on a "try-before-you-buy" basis and attempt to have their software enforce the terms of a trial license. It shows just how easy it can be to inspect and tamper with commercial Java applications.

You should read my candid review of SurfinShield 2.0 before you purchase or install any of their products. You should also read the facts about how they and their lawyers have tried unsuccessfully to suppress my review. I urge everyone who has to deal with Finjan, the company and their products, to do so with a critical and skeptical mind. As you'll see, many of their claims wither when exposed to daylight.

The hostile applets that were featured here have been removed. They had become the source of too many complaints. (That tells you something about the security of Java.) If you would like to try them out, you can do so at a newer mirror site. The source code and lots of useful information are still available here. You are welcome to download them and start experimenting with your own hostile applets.

• Here's a bear that insists on marching to the beat of a different drummer.
• This simple applet can bring Netscape 3.0 to its knees.
• Here's another applet that makes Netscape 3.0 hang.
• This one makes Netscape 3.0 keel over after giving you enough time to go elsewhere.
• This applet asserts its good intentions, but then tries to take control of your workstation.
• This unfriendly fellow attempts to pop up an untrusted applet window in disguise. If you quit, it will attack you; but if you send a login and password....
  When the applet happens to be successful, your host name, IP address, login, and password will appear in the logfile in this directory.
  [I've shut this one down, but you can still see some of its results.]
• By all appearances this applet seems to do nothing, just as it asserts. In reality, however, you will be factoring an integer and reporting the results back to me. (The integer appears on this web page as the parameter named "tobefactored," and the results of your factoring calculations will appear in the primelog in this directory. The results may take a few moments to appear, so feel free to browse around elsewhere and return later.)
  [This one is also shutdown, but you can still see some of its results.]
• This one is a self-defending applet killer. It will stop any other applets that are running and kill any applets that you load after that.
• Try this Netscape forking hostile applet too.
• If the little applet included on this page was successful, in a moment you'll find your e-mail address (including your user name) added to my list of penpals. [Unfortunately, I had to shut it down because it was starting to cause the server some problems, but you can still see some of its results.]

• The source code for these hostile applets and applications is now available.
• Here's an introductory article about them. A slightly different version of it appears in a Java book , which you can read online.
• And here's another old article that appeared a couple of years ago in the Online Business Consultant's "Java Black Widows" series.
• The scope of Java Security has been defined so narrowly as to exclude, by its very definition, significant programmed threats, and the complexity of Java, when combined with its ease of programming, entails a certain amount of risk. Many of the problems posed by executable content have not been solved, and the wider issues of security within the Java Platform have scarcely been raised. In this old article, which appeared in the Spring 1997 issue of the Computer Security Institute's Computer Security Journal, you'll find an overview and analysis of older Java security problems as well as some thoughts on the dangers of Java applications, including several illustrative examples.
• Gary McGraw and Edward Felten have written fine little book on Java Security. I highly recommend it as an excellent introduction to the subject, and you're welcome to read my review of it, which appeared in the May 1997 issue of Web Informant Magazine.
• There is no one-to-one correspondence between Java source code (programs) and Java byte code (class files). The set of all class files which pass the Verifier is much larger than the set of all class files which can be produced by a Java compiler. Class files which could not have been produced by any Java compiler and which still pass the verifier pose a significant threat. Moreover, it is extremely easy to alter class files while preserving their ability to pass all of the Java Verifier's tests. A forthcoming paper, "When Java Was One: Threats From Hostile Byte Code" (PostScript version) discusses byte code hacking and the incoherence between Java source code and byte code. It also examines several examples of deviant byte code and Java Platform Viruses. [This paper has been accepted for publication by the 20th Annual National Information Systems Security Conference. ] A PDF version is also available.
• An article on deviant byte code and Java viruses appeared in the March 1997 issue of the Information Security Bulletin, published in the UK.
• A related article on deviant byte code is also available.
• Here are some transparencies that I prepared for a brief presentation on hacking hostile byte code. I used them a couple of years ago when I gave a talk on the subject at Reliable Software Technologies Corporation.
• In the 1997 releases of the Java Developer's Kit the distinction between applets and applications will start to disappear. We should expect that in the future the dangers posed by Java applets will pale in comparison to those posed by Java Platform viruses and other Java-based threats. The application HoseMocha.java produces deviant class files by adding dead opcodes to standard class files, and it defeats the Mocha decompiler in a dramatic way. PublicEnemy.java is a Java trojan horse that directly attacks classes by making all of their fields and methods public, among other things. The application Mutator.java shows how a class file can induce mutations in itself, remain viable, and take actions based upon its history - a very useful skill for viruses and trojan horses. Mutator1.java is an update of Mutator.java for Version 1.1 of Java. These applications illustrate the potential for hacked class files to yield nasty surprises.
• You should read my candid review of SurfinShield 2.0 before you purchase or install any of their products. You should also read the facts about how they and their lawyers have tried unsuccessfully to suppress my review. I urge everyone who has to deal with Finjan, the company and their products, to do so with a critical and skeptical mind. As you'll see, many of their claims wither when exposed to daylight.
• This new article examines the products of several companies that market their Java-based software over the Internet on a "try-before-you-buy" basis and attempt to have their software enforce the terms of a trial license. It shows just how easy it can be to inspect and tamper with commercial Java applications.
• This latest article in the series examines Finjan's SurfinGate 2.0, SurfinCheck 1.0, and SurfinShield 2.0 for Windows NT. It illustrates just how easy to slip applets past SurfinGate, and it shows how to write applets which SurfinShield cannot stop.
• In my recently begun study of the various available Java decompilers, I decided that a fair test of their abilities would be to attempt to decompile all 1669 class files in the Netscape Communicator 4.04 distribution. I could not resist the temptation to inspect some of their output to see if I could turn up opportunities for hostile applets. Here are a few of the problems that I found. Like the original collection of hostile applets, these exhibit a range of unwelcome behavior - creating ClassLoaders (!), filling up your hard drive (!!), crashing the browser, hosing the Java audio player, forging theSystemPrincipal, and locating your plugins - not a very friendly collection of applets.
• There is a real need to scrutinize all types of Java-based products for security problems and to candidly report those problems in a public forum. This has the desirable dual effects of alerting users to threats and bringing market pressure to bear on vendors who continue to offer flawed products as secure solutions. In keeping with this line of thinking, we have recently taken a hard look at Sun's Java Wallet. This new group of hostile applets shows that they have a long way to go before they can claim to offer a secure electronic commerce product.
• Sun's Java Web Server and IBM's WebSphere both offer a handy admin applet and admin servlet for web server administration. In our latest report we show how easy it is for an attacker to find an admin servlet and to launch a dictionary attack on the web server's administrator password by manipulating it.
• We were recently called upon to take a look at Phaos Technology's SSLava Toolkit. What we found was quite a suprise. If you're in the market for such a toolkit, we recommend that you read our candid report before you buy.
• In addition to my articles and source code, you might also like to read some recent papers by Dean, Felten, and Wallach on Java Security. For a more complete introduction to the subject, check out Java Security: Hostile Applets, Holes and Antidotes by Gary McGraw and Ed Felten. It's an excellent book, and I highly recommend it.

...if you want to learn more about Java (In)Security. The most comprehensive and up-to-date resource is Gary McGraw's Java Security Hotlist. There you'll find almost everything you need to know about the subject. If you don't visit this site often enough, you might end up like poor Duke.

It's been almost two years now since I defended my doctoral dissertation and completed my Ph. D. in Applied Mathematics. In my spare time since then I've developed a handy assembly language as well as an assembler for Java class files. This should prove to be a handy tool for further investigation of weaknesses in the Java Verifier. I've also been working on applying integer programming to cryptanalysis. If you're interested, you can drop me a line if you like. You'll find me at