1

Poison Java By Eva Chen, Trend Micro

Author’s Note Secure Computing magazine awarded this article “Best Security Article” in 2000. Trend Micro commissioned Hoffman Publications, Inc., to write this story, which originally appeared in August 1999 in IEEE Spectrum Magazine’s feature entitled “Poison Java” under the name Eva Chen, CTO of Trend Micro. Introduction In just four years, Java has taken the networked world by storm. The rate of adoption of the programming language has broken all records, to the undoubted delight of its originator, Sun Microsystems Inc., Mountain View, Calif. Today there are hundreds of thousands of Java developers worldwide. In a recent study, Forrester Research Inc., Cambridge, Mass., found that out of those Fortune 1000 companies who responded to the study’s survey, 72 percent are planning to use Java as part of their software development This avid interest is more than justified. Java does what no programming language has done before. It combines powerful, object-oriented programming with the ability to run on any computer platform—Macintosh, Windows/Intel, Linux, and Solaris machines, as well as many others—without the need for recompiling or translating. One result of its platform independence is that a scrap of code called a Java applet can be embedded in a World Wide Web page. When a user comes across a page while browsing the Web, the applet downloads with the page and automatically executes, regardless of the type of computer being used. The appeal is obvious. Web page designers who use Java applets can produce a multiplicity of animated effects, adding movement and dimensionality to previously static pages. The stock prices that scroll across the bottom of a screen at some Web sites may owe their motion to Java. Less obviously, Java promises to play a yet more fundamental role in the future of on-line computing, including electronic commerce, for it can make powerful applications easy for anyone anywhere to access and use. It owes this facility to its ability to hop from computer to computer, for which reason it is also referred to as active content or mobile code. Nonetheless, programmers of all sorts—from the nefarious hackers of the Chaos Computer Club in Hamburg, Germany, to serious software researchers at Princeton University in New Jersey—have demonstrated a dark side to Java. Malicious Java code has the power to delete or corrupt files, monopolize system memory, and even forge e-mail messages and send them out, if it is released in the wild (meaning not in the laboratory, but in the real world). And compared to other software with an evil bent, it can be much more surreptitious, entering the user’s machine and activating itself without warning.

2

A malicious taxonomy Computer viruses currently plaguing the corporate world are classified as a subset of the more generic class: malicious code. By definition, a virus is any code that not only has some unwanted effect on information resources (as does all malicious code), but can also propagate by replicating itself. Self-replication, the distinguishing characteristic of viruses, is what makes them so dangerous; without it, they would quickly die out. But because they can copy themselves into any compatible software-environment “host” with which they come in contact, they proliferate at an alarming rate. In a 1998 survey of the prevalence of computer viruses, the independent industry watchdog organization, International Computer Security Association (ICSA) Inc., Reston, Va., found they had infected over 99 percent of large and mid-sized North American corporations. For the most part, those infections are due not to malicious Java applets but to macro viruses—viruses implemented using macro commands. Most often, the cause was a macro virus embedded in a Microsoft Word or Excel file attached to e-mail. The earlier macro viruses did not harm files but merely caused inconvenience (like locking up their prey’s machine and so forcing a restart), but the latest variety can seriously damage systems. Self-replication is no longer the only way to proliferate. Every time someone accesses a Web page with Java code, the code is automatically downloaded and run. So now the Web can serve to propagate malicious code. The fact that malicious Java code is not yet rampant is no reason to ignore it, for history tells us it will start sacking and looting. The evolution of the virus threat has mirrored the evolution of people’s computing habits: as the desktop computer evolved from a computing into a communication tool, the means of spreading malicious code shifted, too (see Figure 1).

Figure 1: Back in the seventies, before the surge in Internet use, viruses were passed around by floppy diskettes. Next, as programs (that is, executable code) became ever more available online for downloading, viruses spread by representing themselves as legitimate software. Then, along with increased use of e-mail came viruses attached to e-mail message as supposedly nonexecutable files, such as Microsoft Word files. With the rise of Java, Web sites and Web pages attached to e-mail are becoming the way to spread malicious code.

3

Promise and threat To repeat, the power of Java lies in its platform independence. Any possessor of a Java-enabled Web browser, such as Internet Explorer or Netscape Navigator, can indulge in Java applets, regardless of the computer hardware or operating system to hand. Platform independence brings with it the capacity for a high degree of customization, since users can interactively tailor the software to meet their specific needs. But interactivity can work both ways. A Java program resident on a Web server can run on a user’s computer and access whatever information about the setup will enable it to perform its job efficiently and without any action on the part of the user. HouseCall, a Java-based virus checking service that can be accessed free of charge from Trend Micro Inc.’s Web site (http://housecall.antivirus.com/), illustrates such capability. HouseCall is able to remotely scan and remove any viruses present on the workstation of someone visiting the site. When the workstation user selects the scan option on the Web page, the server downloads a Java applet that accesses whatever workstation computing resources (central processor, memory, operating system, hard disk, network connections, or other system assets) it needs to complete its task. While Java is the most prominent language for developing such active content, or mobile code, it is not unique. Microsoft ActiveX controls (see “Another option in mobile code,” at the end of this article) and Netscape JavaScript are also widely used. Lesser-known active code languages include Safe-Tcl, Telescript, Word macros, and Excel macros. Active code is highly attractive to businesses. Huge productivity gains can be realized from the powerful, highly customized business system applications based on active content now being developed and deployed. Today, businesses are using active content to host secure on-line banking, securities trading, and electronic shopping, as well as collaborations on inter-company projects. Active content applications are starting to streamline transactions and collaborations between business partners and their diverse customers. Businesses are using the public Internet, private intranets, and private, secure extranets for these tasks. But active content, with its ability to make free use of a computer system’s resources over the Internet, can be a double-edged sword. To perform any useful local processing, active content must reach deep into local computers. There, it can perpetrate such “crimes” as erasing data stored on hard disks or surreptitiously copying and transmitting data to eavesdropping third parties, just as readily as it can facilitate productive collaboration or transactions. Security managers at large companies, while aware of the dangers implicit in Java, for the most part are doing little about it (see Figure 2). They allow Java applets to enter their network unchecked, and do not even use software to alert them to the applets’ entry into their domain. Nor has the release of Java 2 last December, with its highly touted security model, done much to quell such security concerns because of the complexity of implementing it.

4

Figure 2: While all but a few of the Fortune 1000 security managers responding to a 1998 survey by Forrester Research Inc., of Cambridge, Mass., were concerned about the threat to security from Java and ActiveX code (top, left), less than a third are blocking such software from entering their network (top, right). Few companies even look for such code, and those that do merely use a firewall to check only if the applet has a valid digital signature. Even though malicious applets are as yet few and far between, prudent managers will take action now. Recent history has shown that tardiness in responding to new security threats is costly. Firms unprotected against the most recent macro virus infections have incurred major costs in recovering from an attack and from reduced employee productivity. Stephen Cobb, director of special projects for the ICSA, said, “The situation is scary. Enterprise IT [information technology] managers...have to set up policy now to prevent users from downloading malicious applets and viruses.” Most analysts agree that malicious code will become a widespread problem, although they disagree on when this will occur. On the other hand, most security consultants do, like Cobb, recommend implementing supplemental Java security sooner rather than later. Attack categories The attacks Java applets could facilitate fall into four categories, namely, those that:

• Modify the system. • Invade a user’s privacy.

5

• Deny legitimate use of the machine by hogging resources. • Antagonize a user.

Of these, system modification is the most damaging. This class of attack includes surreptitious alteration of financial records (which can lead to financial loss) or tampering with medical records (which can lead to fatally incorrect treatment). As yet, though, the Java-based variety of this attack has not been seen outside the laboratory. In contrast, examples of the other three classes of malicious applets are readily available. In fact, a large collection of them, complete with source code, is posted on a certain Web site; in July 1998, malicious applets from this site were used to launch a real attack that could affect anyone using Netscape browser versions 4.04 and 4.05. (Note that IEEE Spectrum chooses not to list the name or universal resource locator of sites that contain malicious applets.) Perhaps the most disturbing malicious applets in the wild are those that forge mail--a form of privacy invasion. The applets can actually compose an e-mail message and send it to everyone on someone’s address list, posing as that individual. Clearly, this could expose that person to a wide range of risks, depending on the content of the e-mail. For example, sending e-mail to the White House threatening the life of the President is a felony, yet it is well within the powers of a relatively simple malicious applet. Forging such e-mail is neither particularly complex nor hard to do. A knowledge of e-mail protocols is the sole requirement. By allowing users to state their identity any way they like and omitting to authenticate an identity, browsers make forgery even easier. Defense against e-mail forgery is quite difficult in Java, while an even greater peril, as more people use systems for commerce and personal information, is the theft of private personal and corporate information. Denial of service is the most usual of Java applet crimes. It encompasses everything that ties up computing resources, preventing victims from doing what they want to do. Like e-mail forgery, denying service is little trouble to implement in an applet, but is a lot of trouble to prevent. Applets of this kind posted on the Web include code that swallows up all a machine’s memory, or opens numerous windows, or consumes processor power, so that a Web browser shuts down. Applets that antagonize the Web user are basically annoyances, whether the playing of incessant sounds or the display of pornography. One humorous applet now in the wild displays a dialog box that says, “April Fools.” When its recipient attempts to remove it by clicking on the OK button, the box jumps around the screen, evading the mouse cursor. (Exiting the browser is the simplest way to close this dialog box.) Several other applets in this category are posted on the Web on, for instance, Mark LaDue’s Hostile Applets Home Page (http://www.rstcorp.com/hostileapplets/index.html). Java security Most industry experts agree that threats from malicious code cannot be prevented by

6

traditional security measures, such as firewalls and data encryption. A certain amount of security is inherent in Java, but two problems remain. To begin with, there is the problem of getting security holes patched. The various Web browsers (Netscape Navigator, Netscape Communicator, and Internet Explorer, among others) implement Java in different ways. Accordingly, different security flaws have been identified in the specific versions of these browsers. Browser makers typically hurry to fix security bugs and make updated browsers or patches available to users on their Web sites. Unfortunately, many Web users fail to download these fixes, thus becoming vulnerable to malicious code, which may even determine the type of browser they are using and tailor its attack to that type. The second problem is that implementing a coherent security policy on malicious applets is an obstacle-ridden and time-consuming task. This is true even for the most recent release, Java 2. Many companies therefore relegate policy management to users, leaving it to them to determine, say, which kinds of applets should be allowed. Inevitably, implementation of security policy then becomes inconsistent. The reason why setting up policy for Java is complex is that Java security evolved in a complex fashion. Security issues raised by active code can be addressed by system administration with so- called sandboxes and with digital signatures. As Java evolved, both approaches made their way into its security model, so that today, Java security is a hybrid of these techniques (see Figure 3).

Figure 3: To provide security, Java began with a simple version of what is called a sandbox, which placed limits on all Java applets. Next, in Java 1.1, Sun Microsystems added digital signatures (left) to the security model, relegating to the sandbox only unsigned applets or those signed by an untrusted source. In the latest release, 2.2, a limited number of applets can run outside the sandbox (right) even if not signed by a trusted source, but the fine-grained security screen required to leave the sandbox is difficult to implement. A sandbox is a software “box” where code of unknown origin (untrusted code) can be run. Untrusted code may be all code that comes from outside a company, which considers

7

only code from its internal Web server trustworthy, or it may also freely allow code from the Web sites of companies with excellent security reputations. The sandbox places tight controls on what the code may do. One component of the sandbox security model in Java 1.0.2 is the security-manager code module, which is very strict about access to local files, including file operations such as read, write, and delete. But constraining the access of each and every Java applet, with no provision for exceptions, would cause a problem. A user may want some trusted applets to have more access to system resources than is allowed in the sandbox so that they may benefit the system, perhaps by searching a hard disk for viruses and removing any they find. Java 1.1, released in the early spring of 1997, attempted to address this limitation by incorporating the digital signature method into its security model. Digital signatures are a form of encryption where binary files are encoded with a digital code, or signature, unique to a developer, distributor, or certifier. Because a digital signature has special mathematical properties, it is next to impossible to decipher and, hence, to forge. Using this technology, a Java applet can be digitally signed (see “Digital signing,” at the end of this article). The idea is that the user decides whom to trust. For example, a company may opt to accept only applets signed by someone on a specific list it develops. All applets signed by someone not on the list (and unsigned applets) will not be allowed to run freely and relegated to the sandbox. This is the essence of Java 1.1 security. Many security administrators are skeptical that a digital signature capability alone can implement a security policy for Java. Recent Forrester research showed that only 20 percent of survey respondents felt that code signing would fully safeguard their systems. What seems to be missing is access control capabilities. Java 1.1 can either accept code or relegate it to the sandbox based on who signed it; but finer control over what each applet can access is needed to provide the flexibility administrators are demanding. Released last December, Java 2 is Sun Microsystems’ response to these needs. Java 2 ’s fine- grained access control allows code with proper permissions to gradually step outside the sandbox’s constraints, with the system administrator granting different degrees of privilege to different programs. With such access control, theoretically, administrators could implement security policies under which certain applets may take certain actions that will be beneficial. For example, an administrator could set up a configuration allowing a certain applet to read and write files in a particular directory and connect to any host in a given domain. But Java 2 security has an Achilles’ heel. According to Gary McGraw and Edward W. Felten in Securing Java, Getting Down to Business with Mobile Code (see To Probe Further), the idea of Java 2 security may be simple, but in practice creating a coherent policy is quite difficult. They assert that “’setting up a coherent policy [using Java 2] at a fine-grained level takes experience and security expertise. Today’s harried system administrators are not likely to enjoy this added responsibility. On the other hand, if policy management is left up to users, mistakes are bound to be made.” In other words, some sort of tool is needed to ease the task of configuring servers to enforce a company’s Java security policy.

8

Client- versus server-side security So what actions do security managers need to take? Not one measure but a combination is needed to reduce the risk that Java applets will breach security. Defenses against the security threat of Java applets run the gamut of client-side and server-side options. The most obvious client-side solution—and most draconian—is to disable Java altogether at each workstation. With Netscape Navigator, for example, users need only select Security Preferences from the Options menu and click on the Disable Java box. But this wholesale approach frustrates users grown accustomed to the added dimensionality of Java applets. As the applets move more and more to center stage on Web pages, disabling them eliminates some applications of value to users. Client-side solutions include the SafeAgent program from the unusually named Security-7 (software) Ltd., Woburn, Mass. They plug into the Web browser at the workstation and do various sorts of screening and applet signature checking. That takes both the load off the server and the brakes off the Internet traffic. At the same time, client-side protection often provides real-time monitoring, of the kind offered by SurfinShield Xtra from Finjan Inc., San Jose, Calif. From the system administrator’s viewpoint, client-side solutions have limitations. Requirements that Java be disabled by various users are hard to enforce company-wide, and they carry more management overhead. Also, dumping difficult decisions on security issues in the client’s lap results in security becoming inconsistent. These drawbacks are addressed by the alternative to client-based solutions: server-based security. Analyst Ira Machefsky of Giga Information Group Inc., Cambridge, Mass., stated in a 1996 report that he believes sites should move to server-based security mechanisms whenever possible, because the latter can save on system overhead and enhance the quality and audit-worthiness of an active-component security policy. Indeed, server-based solutions are single-point implementations of a security policy that users cannot subvert at their desktop. For example, at the gateway to a protected network, Finjan’s SurfinGate inspects Java code using a process that emulates the code’s likely actions. The process assigns a unique ID and applet profile to the code, noting any possible security breaches, according to Finjan. This type of protection, while readily deployed and managed, can also place a heavy load on the server and can slow Internet traffic. And while an emulation process like this one can model many likely applet actions, it cannot model all of them. That loophole may set an applet at liberty to undertake unmodeled and potentially malicious actions. Hybrid help A hybrid solution to supplementing Java security was recently released by the author’s company, Trend Microsystems Inc. Called InterScan AppletTrap, the software integrates elements of both client- and server-based solutions (see Figure 4). It employs a proxy server, one that acts as an agent for the server to prevent an attack on the security software. Using the proxy, AppletTrap first weeds out unwanted applets as HTML pages

9

are downloaded, checking to see whether the applet is on a list of those to be blocked out. To check the applet, the program uses the 32-bit MD5 message-digest algorithm (created by Ronald L. Rivest of the Massachusetts Institute of Technology, best known as a co-inventor of the RSA public-key cryptography system) to create a hash code of the applet, which it compares to those on its list. Any applets found on the list are at once discarded. Next, the software runs a certificate check on the applets and blocks any that are unsigned, signed by an unrecognized certificate authority (see “Digital signing”), or signed with a signature that does not match its content.

Figure 4: Supplements to built-in Java security create a three-tiered approval process (bottom row). First comes a check to see if an applet is on a list of blocked code (left). Next, it is examined for a signature from a reliable source (middle). Then it may run, but is watched in real time in case it attempts an action, like erasing disk files, that security rules forbid. After this prefiltering, applets with calls to system resources are prepared for more thorough examination. The preparation process is referred to as instrumentation. During it, AppletTrap wraps monitoring code around the applet and attaches the security policy that determines what system resources it can access. Depending on how AppletTrap is configured, this security policy can vary from one intended recipient to another. During instrumentation, the addition of extra code in effect deprives the applets of their original signatures. However, system administrators can configure AppletTrap to re-sign the applet before it is sent to the client workstation. The re-signing ensures that applets are delivered uncorrupted to client workstations and facilitates management of the client certificate database.

10

The HTML page, along with the instrumented applets, is then delivered to the client and displayed on its Web browser. Once the applet is invoked, AppletTrap’s monitoring code extracts information about the resources that will be used by the applet and ascertains the permissibility of this action by comparing it with the attached security policy. If the action is permitted, AppletTrap allows the action to take place. Otherwise, it carries out an action predetermined by the security administrator—typically some combination of blocking the applet and notifying the user. Whatever the action, AppletTrap notifies the server of any malicious applets detected at the client workstation for automatic inclusion in the list of the rotten applets to be blocked. The advantage of this approach is centralized protection, with control, deployment, and management functions at the server. Also, the load on the server is lightened, because the real- time monitoring runs automatically at the client’s end. To probe further Surveys on Java security are just starting to become available. “Securing Java and ActiveX” by Ted Julian, et al. appeared in Forrester Report, Network Strategies (Vol. 12, no. 7, June 1998). The publisher is Forrester Research Inc., at www.forrester.com. In the same year the International Computer Security Association Inc., Reston, Va., produced the “ICSA 1998 Computer Virus Prevalence Survey.” The survey was conducted to identify the extent of the virus problem in desktop computers and computer networks. For the first time, the annual survey includes exploratory questions about Java applets. The survey may be down loaded from the ISCA Web site (http://www.icsa.net/services/consortia/anti-virus/). Computer security expert Gary McGraw and Internet security guru Edward W. Felten recently published a revised edition of their Java security book, Securing Java, Getting Down to Business with Mobile Code (John Wiley and Sons, 1999). It expounds on several security flaws in various Java implementations discovered by a Princeton University team. Ira Machefsky wrote “Planning Assumption: Java and ActiveX Security Options—A Growing Web of Products” (PA, I-96-1234) for Giga Information Group, 1 January 1996. The article compares six types of security solutions for Java applets, discusses server-side and client-side options, and presents recommendations. It can be obtained from the Giga Information Group Inc., One Longwater Circle, Norwell, MA 02061. Phone 1 781 982 9500, or check the Web site at www.gigaweb.com. © Copyright 1999 IEEE, and Hoffman Publications, Inc. All rights reserved.

11

Another option in mobile code

While Java is by far the most popular Web-based mobile code or active content, there are others, and each poses its own challenges. Most often mentioned after Java are Microsoft’s ActiveX controls, which have similar capabilities to Java applets but a distinctly more limited security model. In fact, security professionals have criticized ActiveX for its weak approach to this matter.

ActiveX relies solely on the trust-based approach of digital code signing, using Microsoft Authenticode. Although each modification to an ActiveX control in the wild must be re-certified with Authenticode, no checking or testing for malicious coding is done in any of the certification processes. Hence, the certification is not an endorsement of the code’s function or intent. It all boils down to clients choosing whom they trust to produce virus-free programs, that is, ActiveX controls.

This determination is a rough one to make, and varies from individual to individual within a company. Many users, already accustomed to clicking “continue” on every warning message they receive on the Web, simply accept all controls regardless of the consequences.

What’s more, compared to malicious Java applets, malicious ActiveX controls are perceptibly the greater threat because of how ActiveX is designed. When an ActiveX control passes through a list of acceptable digital signature sources, it does so unfettered by the sandbox that Java imposes on its applets.

Nonetheless, one way of warding off malicious ActiveX controls is to use software that checks the controls’ certificates and compares them with the list of recognized certificates in the Microsoft Internet Explorer database. All unsigned controls and controls not carrying recognized certificates can then be blocked. As Internet Explorer’s default certificate database is modifiable, it frees administrators to selectively accept or reject any ActiveX controls.

-E.C.

12

Digital signing

Public-key cryptography is the basis for the digital signatures used in Java code. In this method, the developer of the code runs a special algorithm to generate two large numbers—a private key and a public key. The developer uses the secret private key to digitally sign code, that is, encrypt it, and everyone else uses the public key to verify this signature.

Since the private key is kept secret, only the developer can use it to put a signature on code. Conversely, since everyone knows the developer’s public key, everyone can verify that the signature on an applet is the developer’s. More specifically, everyone’s browser can compare the developer’s registered public key to the signed applet, enabling the browser to reject the applet if it is not from the developer.

Further, an independent third-party company whose reputation for honesty has been established is used to certify that developers are who they say they are. The certification authority (CA), as the company is called, prevents the forgery of digital signatures on applets. The CA first verifies a developer’s identity in person and issues that person an electronic credential. The developer then attaches a copy of this credential to each signed applet. As a result, the recipient of an applet can first electronically check the developer’s credential and then check the digital signature.

-E.C.