A New Buzzword
The Java security community has begun to use a new buzz phrase, mobile code', to describe Web executable content like Java, JavaScript and ActiveX. The name is meant to distinguish it from non-Web forms of executable content, such as Microsoft Word macros and PostScript. All executable content has the potential to cause security problems - MS Word macro viruses have caused more damage than all other executable content attacks combined. Some future operating environment, such as Project Spin, may well be robust enough to resist multiple forms of executable content attack, but for the time being, the security controls of each type must be handled separately. This month's article will examine two commercial efforts to centrally control mobile code; specifically, misbehaved Java applets.
Finjan
Finjan became the first commercial developer of a Java security enhancement last fall when they introduced SurfinShield, a software add-on that allowed workstation users to prevent the execution of Java applets by their browsers. Evidencing a high rate of new product introduction, Finjan hasn't limited itself to Java and the current product, SurfinShield Xtra 2.0, guards against both undesired Java applets and ActiveX code. SurfinShield, which claims to prevent e-mail attacks, has the potential to protect against hostile code or URLs to hostile code that are anonymously sent to a Java-enabled e-mail client.
SurfinGate is an organization-level control designed to prevent damage from hostile mobile code. Positioned as a supplementary firewall, it checks Java applets for hostile intent before they ever reach the client. Running on a server at the organizational boundary - normally immediately behind a firewall - it allows an administrator to set an organizational Java security policy for allowable Java capabilities. Applets that attempt to write to a file or communicate with a host other than the originator are identified as such by Finjan's scanner, allowing a decision to be made as to whether the applet should be provided to the requesting user.
Finjan's product maintains a database storing identification and security-relevant information on every applet it encounters. It actually scans the byte code to analyze the applet's intentions, storing its characteristics in the database. While it will be able to take full advantage of signed applets, it can also provide some of the characteristics of signing even to unsigned applets. Every incoming applet is identified and only those meeting the security criteria are allowed inside the organization.
SurfinGate compares incoming applets to a list of known applets in its database, including all known hostile applets (a fairly small list today). Unrecognized applets are scanned for potential hostile behavior, generating an Applet Security Profile that is stored for the next encounter with the applet. The ASP, whether previously stored or just generated, is compared to the site and user security policies to determine if the applet is acceptable for use.
A free download and lengthier descriptions are available at http://www.finjan.com.
Digitivity
A subsidiary of APM Ltd., an eight-year-old British consulting firm, Digitivity has managed to generate much media attention for its approach to Java security. Digitivity is unique in not running the Java applet on the workstation at all, but instead running it on a special server and sending the graphical output to the workstation using a proprietary protocol.
Digitivity's product sprang from a consulting project that APM was performing for a large bank. They were developing a Java applet for use by the bank's customers. Since the bank had already disabled their own access to Java applets on the Internet at their firewall, their customers asked why they should be expected to use the bank's Java applet over the Web when the bank itself was unwilling to do so. Good question. As APM began developing a solution that could allow the bank's partners to access the Java applet without putting them at risk from other Internet Java applets, it became clear that a solution to a universal problem might have wider commercial applicability.
The Applet Management System currently consists of two server components and a client component. The AppRouter, which normally would sit directly behind the organizational firewall, is used as the Web proxy by the client browser. It intercepts requests to download Java applets and instead of providing the applets themselves to the browser, it forces browsers to load Digitivity's proxy applet. The AppRouter provides direction to a CageServer, usually located outside of the firewall, to download the Java code. Following instructions from the AppRouter, the proxy applet connects through the firewall to the CageServer and uses the BrowserBridge protocol to display the graphical interface of the applet, which actually runs on the CageServer. BrowserBridge protocol is unique to Digitivity but is functionally identical to Citrix's WinFrame or the X Window System.
The architecture, which is unique among the others examined in this series, offers advantages in scalability. There is no need for a one-to-one correspondence between AppRouters and CageServers. A single AppRouter can serve multiple CageServers. Beyond what the sandbox provides at the browser level, Digitivity touts a number of benefits for this architecture:
Quarantines outside or unacceptable mobile code so that it never runs on the user's desktop
Centralizes Internet applet execution to facilitate common management
Prevents users from making undesirable changes in their environment that violate organizational security policies
Runs applets on a platform optimized as a secure environment
Digitivity plans several important upgrades over the next year. The Policy Cage will take advantage of signed Java applets to allow centralized management of access control. The Enterprise Cage will support the deployment and coordination of multiple CageServers and will interface with the major network management systems.
According to Andi Bruno, Digitivity's Director of Marketing, "People resonate with the very physical form of protection we offer and the way in which our three announced products provide a series of stepping stones from applet security to applet management to enterprise applications. Once established, it is centrally controlled and administered. The entire process is transparent to end-user. We've taken the locus of control away from the desktop/browser and end-user and put it under central administrator control and management at the server level."
For more information on Digitivity, see www.digitivity.com.
Is All This Necessary?
This is a good opportunity to apply some of the security concepts that we've discussed over the last few months. Finjan and Digitivity, along with the students and faculty at the Secure Internet Project and Project Kimera, make security countermeasures. The decision-making process leading up to the application of a security countermeasure is called risk analysis. To analyze the risk of allowing users to run Internet-borne Java applets, we'll examine vulnerabilities, threats and the cost of a successful attack.
Vulnerability
At this point in time, the current versions of Internet Explorer and Netscape Navigator seem resistant to known attack methods. The process of examining the products for weaknesses that might be exploitable is called flaw hypothesis methodology. This approach has identified virtually all of the security bugs discovered in the popular browser products (HotJava included). Attempting to predict the future based on past events has been compared to driving a car by looking out the back window. Point taken, but if your car doesn't have a front window, you can make some educated guesses based on what you see out the back window. Sometimes the past record is all we have. Historically, computer science has identified a steady stream of browser security holes that the browser vendor has quickly plugged with updated code. Looking out the back window of the browser lifecycle car, it's reasonable to assume that Netscape and Internet Explorer probably have unknown security holes.
Threat
So far, the threat population of hidden hostile Java code is empty. There are no public records of known attacks through the use of Java applets (or ActiveX). Well-marked Web pages containing hostile code are available to the curious, but there are no documented incidents of this code being used for hostile attack. People who are known to attack computers - either through viruses, Trojan horses or by directly cracking a system over the Internet - represent a statistically significant threat population. Based both on history and knowledge of human behavior, it is reasonable to assume that easily exploitable vulnerabilities will be subject to attack. So far, Java applets have not become a convenient means of system exploit, unlike viruses, which are anonymous and self-replicating. Hostile applets are hard to insert and they don't spread, making them much less efficient for system compromise.
Value
What would it cost your organization to be hit with annoyance applets or data theft applets? You've probably encountered computer viruses and maybe Trojan horses transmitted by e-mail. What was the effect on your organization?
The Bottom Line
The vulnerability of individual systems is low, but unrecognized weaknesses are likely. The current threat is almost nonexistent, but a significant population of potential attackers exists who would take advantage of Java vulnerabilities if it were convenient to do so. The cost of a successful exploitation varies from organization to organization, but could be incredibly high for organizations handling financial transactions or other sensitive data. Analysis of risk, choice of policy and implementation of security countermeasures are judgment calls that will legitimately vary from organization to organization.
While there are still no documented cases of hostile mobile code being anonymously transmitted through a Web page, there are many cases of hostile code, especially macro viruses and Trojan horses, being sent through e-mail. If you are actively receiving Internet mail, but not protecting against e-mail threats, you are vulnerable to a well documented threat. Consider protecting your organization from e-mail pathogens before spending resources on Java threat countermeasures. If you or your management has strong reservations about the use of external Java code, but must use it to remain competitive, one of these products will go a long way towards reducing your concerns and vulnerability. My personal opinion is that for most organizations, the threat represented by Java applets on the Internet is minimal. However, as Java becomes increasingly common and signed applets gain system privileges, centralized and effective control mechanisms - especially for external code - will become routine. Next month's article will look at Netscape's and Microsoft's plans for providing this centralized Java policy control.
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
