How secure is the Java Wallet
Most readers are probably aware of the numerous security problems discovered in the past two years in Java-enabled Web browsers. Hostile applets remain a threat, even in the latest browsers, and third parties who claim to offer tools to bolster security frequently fail to do so. Thus 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 potential 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 close look at Sun's Java Wallet. Our examination revealed a number of problems that allow untrusted applets to exploit systems on which the Java Wallet is installed. Among our examples are applets such as the following:
Since the Java Wallet is a recent and evolving product, we begin with an overview of its key components before moving on to consider several of its problems. For more details, the reader is invited to consult The Java Wallet Architecture White Paper and the Java Commerce Business Perspective from Sun Microsystems which are linked from the bottom of this article.
What is the Java Wallet?
There are at least two distinct senses in which the term Java Wallet is used. In its broadest sense, the Java Wallet is simply the Java Electronic Commerce Framework (JECF). In a non-O'Reilly nutshell, the JECF is designed to be an open, extensible architecture for developing secure electronic commerce applications in Java. It consists of a number of application programming interfaces (APIs) that extend those of the Java Developer's Kit (JDK) as well as a suite of tools to assist developers in building electronic commerce applications with those APIs. (These APIs are sometimes collectively referred to as the Java Commerce Client (JCC) Framework.) In its narrower sense, the Java Wallet is a program with a wallet-like graphical user interface that can be used for on-line purchasing and numerous other financial transactions. As such it is one of the JECF tools developed by Sun using the JECF API's. It is in this narrower sense that we consider the Java Wallet.
In order to better understand how the Java Wallet can fail, we first review some of its key concepts and components. We may enumerate these briefly as follows:
This review of the Java Wallet's main components, while perhaps too brief, should be sufficient to understand its problems. Though a commerce server can invoke a user's Java Wallet in a variety of ways, most of these will not concern us here. Our main interest lies in exploring what untrusted applets can do when the Java Wallet is present. Two of our applets will simply employ the Java Wallet's classes to obtain unauthorized access to sensitive information and services on the user's machine. Though a third applet will invoke the Java Wallet, it will do so in trivial way in order to induce a careless user into using a "Help Contents" button whose behavior the applet has altered.
We are now ready to take a look at three examples of untrusted applets that exploit weaknesses in the Java Wallet. In order to develop these applets, we downloaded the Java Wallet (Early Access Release 1) and installed it according to the instructions. Since the Java Wallet required Sun's Java Plug-in 1.1 to be installed, we downloaded and installed that as well. We later learned that the Java Wallet does not always work properly with the Java Plugin, and so we also installed it with the Project Java Activator (Early Access Release 3). Unfortunately, our example applets work with both the Activator and the Plugin-in.
Pickpocket: an applet which steals information and passwords from the Java Wallet
Applications that save login and password data for your convenience are always tempting targets. Unfortunately, Sun's Java Wallet offers this feature, and we found that it is easy for an untrusted applet to recover any saved information. Our first example shows how an applet can discover the Java Wallet's home on a user's machine. This necessarily contains the user's home directory (according to the user.home property). The example also shows that an applet can read the Java Wallet's properties file (jecf.properties). This allows the applet to gather saved user login data and "decrypt" saved passwords.
To test this applet, you first need to set up Sun's Java Plug-in (or Activator) and Java Wallet, and you need to create and save a wallet as the default for auto-login. We set up a wallet with a login name "dummy" and password "easy2read," and then we ran our applet. This yielded some very interesting information. You can also read the source code to see how applets can easily access the jecf.properties file. Clearly some restrictions will need to be placed on this applet capability. Using a BASE64Encoder to "encrypt" passwords is also not a very good idea.
BookMarker: an applet which alters the behavior of the Java Wallet's "Help Contents" button
Our second example demonstrates how an untrusted applet can alter the behavior of the Java Wallet's "Help Contents" button. On Solaris systems this allows the applet to execute commands via Netscape's Communicator when that button is pressed.
In order for the "Help Contents" button to function at all, the user must have already set the property jecf.browser.path in the file jecf.properties. Since this is an apparently unadvertised feature of the Java Wallet, a second applet runs on the same page as the BookMarker and prompts the user to set that property. Note that this applet runs via the Communicator's own Java Runtime and that it uses Netscape's security apparatus to display Netscape's certificate along with its own message.
In order to try these applets, you need to set up Sun's Java Plug-in (or Activator) and Java Wallet along with Netscape's Communicator (4.04 or 4.05) on a Solaris system. You should also have Sun's Purchase 1.1 Java Wallet cassette and a Java Wallet user set up. Then you should be able to run the applets.
Helper.java retrieves private information about Netscape's System Principal by creating a handy encoder. It then creates a fake System Principal and uses that to display Netscape's certificate along with a message asking you to verify that jecf.browser.path is properly set in jecf.properties. If this social engineering effort works, the Java Wallet's "Help Contents" button will function and be able to do the applet's bidding.
BookMarker.java first downloads a bogus Java Commerce Message to start the Java Wallet. Once the Java Wallet is started, the applet can gain access to the field JECF.globals.releaseBundle and set that to a new ListResourceBundle of its own construction. The bogus Java Commerce Message causes the Java Wallet to display a phony message about an internal test along with instructions to press the "Help Contents" button for more information. If you do so, the applet then adds a bookmark to the Hostile Applets Home Page to your bookmarks.
Note that on Solaris systems lots of other options are available to the applet. Using the -remote flag allows the applet to run any of the Communicator's xfeDoCommand options. Using the -java flag allows the applet to have the Communicator's Java Runtime execute any Java program in your CLASSPATH. For example, this particular ListResourceBundle allows the applet to set up a ServerSocket and echo server on your machine. Clearly the ability to change the behavior of the "Help Contents" button can lead to much mischief.
DemonDialer: an applet which can use your modem
Our third example shows how an untrusted applet can exploit the Java Wallet to access the serial and parallel ports on your machine. This particular example, DemonDialer.java, first looks at all of the available ports on your machine. When it discovers a serial port, it lists some of that port's properties. If a given serial port is free, the applet opens it and looks to see if a modem might be attached. If so, the applet sets some modem properties and then dials out. If the serial port is not free, or if something goes wrong, the applet sleeps for 10 seconds before trying again. The applet also resurrects itself in case of ThreadDeath and keeps going.
While this applet merely dials a toll-free number and waits 60 seconds before hanging up, it is easy to make the applet run up charges on your phone bill, connect to an evil modem with a computer waiting to attack your machine, and many other nasty things. Note that the applet will keep dialing out, so you will have to exit your browser in order to bring it to a halt. If you download the applet over your modem, the applet will lurk in the background and attack once your modem is not in use.
To try this applet, you first need to set up Sun's Java Plug-in (or Activator) and Java Wallet on a machine running Windows NT or Windows 95. It works for both Netscape's Communicator (4.04 and 4.05) and Microsoft's Internet Explorer (4.0 and later). If you still want to try this applet, you'll have to do so at your own risk.
The Java Wallet and its problems
While troubles like these are serious and embarrassing for vendors of any product that touts itself as a secure solution to the problems of electronic commerce, they need not be fatal for the Java Wallet. It is clear that they can all be corrected by properly restricting public access to methods in the Java Wallet's classes. (Saving login and password information, while perhaps convenient for the user, is a foolish feature that should be removed from future releases of the Java Wallet.) All of these problems may, however, give another black eye to electronic commerce and leave lingering doubts in the public's mind about the wisdom of trusting products like the Java Wallet. In that regard the Java Commerce team may be shooting itself in the foot by releasing a product with too many obvious flaws. We can only hope that as electronic commerce, Java Security and the Java Wallet all mature, we will see fewer and fewer such problems in Java-based products.
Links on this article:
Mark D. LaDue is currently a senior systems engineer at GTE in Irving, Texas. There he works on designing secure electronic commerce products for corporate clients. You can contact him at firstname.lastname@example.org and Mark.LaDue@ap.bdi.gte.com.