Security issues surrounding the JavaÔ programming language
Abstract
JAVA is claimed to be a programming language that introduces new methods for platform‑independent development and remote execution. However, the ability to download, integrate, and execute code from a remote computer raises serious concerns about JAVA’s effect on network security. In this paper, a brief introduction to the JAVA programming language is given, the potential security risks of downloadable executable content is discussed, the details of the proposed JAVA security mechanism are presented, and an evaluation of the current implementations is discussed. Finally, proposed enhancements and upcoming extensions to the security model are described.
Keywords
Java security, applet, mobile code.
1. INTRODUCTION
The concept of downloadable executable content is not a new one. The explosion in use of the World Wide Web we are currently experiencing coupled with rapid evolution of the JAVA programming language has given insights into downloadable executable content and at the same time raised some important security issues.
JAVA is an object oriented programming language developed by Sun Microsystems. It introduces new methods for platform-independent development and remote execution. JAVA is a language that provides for the creation of mobile code, which can be run unmodified in a variety of systems. JAVA applets and servlets can be executed within any JAVA enabled browser in the users host machine even if they originate anywhere in the network. However, security concern becomes especially strong in such an environment, since the presence of downloaded executable content makes the local computer vulnerable to a potential attack from the (possibly untrusted) source of the executable. JAVA during the past few years has undergone major alterations with respect to both its content (libraries, capabilities, structure) and its security mechanisms. Now, in the new versions, it promises that through its new designed security mechanism, provides a secure environment for downloadable executable content that under specific circumstances can make use of a system’s resources without compromising their availability and integrity.
This paper addresses the security problems associated with the JAVA programming language and provides some solutions for them. Section 2 provides a brief overview of the JAVA programming language focused particularly on the manner JAVA addresses downloadable executable content security issues. In section 3, the problems that would arise when running untrusted programs without providing a secure environment are investigated, and section 4 takes a closer look at the solution provided by the JAVA security model. Current implementations as well as upcoming extensions are presented in section 5, where their efficiency and flexibility are evaluated, and proposed enhancements are generally discussed in section 6. Finally in section 7 concluding remarks are presented.
2. JAVA LANGUAGE OVERVIEW
JAVA is a general purpose, object oriented language inheriting its characteristics from C++ and Smalltalk. One of the major design goals of JAVA is portability. A JAVA program is portable in the form of binary code. This code can be executed by a wide variety of systems, through the JAVA Virtual Machine (JVM). The latter is a software program that implements a virtual machine (Sun, 1997b), (Sun, 1997c). The virtual machine insulates the application from differences between underlying operating systems and hardware and ensures cross platform compatibility among all implementations of the JAVA platform.
The JAVA compiler compiles JAVA code to an architecture independent object file format, namely the class file, as illustrated in Figure 1.
Figure 1. Compiling program statements into bytecode
The JVM consists of:
· an instruction set, equivalent to the instruction set of a CPU
· a register set
· the class file format
· a stack
· a garbage-collected heap
· memory area.
To execute JAVA class files, known as bytecodes, a runtime environment is needed which interprets these bytecode instructions of the virtual machine and executes the assembler instructions appropriate for the particular processor. This runtime environment is usually provided by a Web browser, into whom the JVM is built. Figure 2 shows how machine code is produced from bytecode.
Figure 2. Converting virtual-machine code into ones and zeros the processor understands
Java programs can be either applets or applications. Applet is the mobile code that can be downloaded and executed by a Java-enabled Web browser. Applets are downloaded along with the HTML document they are incorporated in; their execution commences automatically after the downloading is completed. Applications on the other hand are programs that are executed in a stand alone fashion. They are purchased and installed by users or system administrators (according to standard policy within an organisation) just like traditional commercial applications. Therefore, JAVA applications add no new security concerns.
JAVA language enhances security (Sun, 1997a) by eliminating features like pointers and runtime casting to prevent illegal access to memory. In addition, security is provided by the JAVA simulator (interpreter) during the load and verification of JVM code. The JAVA interpreter inside JVM has three main tasks:
· code loading, performed by the class loader
· code verification, performed by the bytecode verifier
· code execution, done by the runtime system.
The class loader loads all classes needed for the execution of a program whether local (resident on the host) or remote (located anywhere on the network). It adds security by separating the name spaces for the local classes and those imported from network sources. The latter are loaded into a private namespace associated with the origin. When a class from its private namespace requires to access another class, local classes are the first to be checked. When all classes have been loaded, the memory layout of the executable is determined. At this point, specific memory addresses are assigned to symbolic reference and the lookup table is created.
Once the memory layout is completed, bytecodes run through the bytecode verifier that tests (Yellin, 1995) the format of code fragments and applies a theorem prover to rule-check code fragments for illegal code - code that forges pointers, violates access rights on objects, or attempts to change object type or class. In other words it ensures that the code adheres to the JVM specifications and does not violate system integrity. If the verifier completes without returning an error then the following are guaranteed:
· classes inside the runtime adhere to the class file format of the JVM specifications
· there are no access restriction violations
· the code causes no operand stack overflows or underflows
· the types of parameters to all opcodes are known always to be correct
· no illegal data conversions have occurred
· object file accesses are known to be legal.
3. SECURITY ISSUES
Security is the practice by which individuals and organisations protect their physical and intellectual property from all forms of attack and pillage. Computers and network configurations are providing new levels of access and consequently new opportunities for unauthorised interaction and possible abuse.
Traditional applications, when running on a computer system, obtain access to certain resources of the system. In a similar way, downloadable executable content could also obtain access to such resources. While it is acceptable for traditional applications to utilise such resources, it is not desirable, at least to a certain degree, for downloadable executable content to do so. This is the case because downloadable executable content is considered to be untrusted and as such could misuse system’s resources. The essence of the problem is that downloading and running JAVA code without placing any restrictions in resources availability, can provide a malicious program with the same ability to mischief as a hacker who had gained access to the host machine.
Hostile applets are a kind of Web-embedded Java programs that perform such hostile activities against Web users. An important part of creating a secure and safe environment for a program to run in is identifying the assets that we are concerned about and providing the classes of potential attacks that may occur. The threats presented by executing Java applets fall in the following categories (Gritzalis, 1991), (Sterbenz, 1996) :
· attack the Integrity of the system. Deletion or modification of files, modification of currently used memory, killing processes and threads are some of the harmful consequences of such an attack.
· violate the user’s Privacy. This can be achieved by sending private or company data to another system via the network.
· limit system resources Availability. It may occupy system assets, making them unavailable for legitimate purposes, by creating thousands of windows, creating high priority processes hence using all CPU time, allocating large amounts of memory, using up all available file pointers.
· achieve user’s Annoyance. It may display misleading information, causing the user to violate security without noticing, or annoy him by displaying obscene pictures on screen, or by playing unwanted sounds.
Apart from security breaches that may be caused directly through Java, there are cases when Javascript can be used by an attacker in order to improve the Web attacks he was performing without it. One of these cases is Web spoofing (Felten, 1997). Javascript provides a potential attacker who implements a spoofing attack through URL rewriting with the ability to replace the status line and the location line of the user's Netscape browser, thus concealing the real identity of the site from which the data derives. Furthermore, Javascript may be used in order to replace the "Document Source" and "Document Information" functions of a Netscape browser with fake ones, designed appropriately by the attacker, which will provide the user with all the necessary false data in order to convince him that he is indeed connected to the correct site (e.g. www.microsoft.com), instead of the attacker's site (e.g. www.danger.com). What actually happens is that the attacker's site uses URL rewriting in order to provide the user with the pages he has requested (Microsoft corp. pages), rewritten in a way that suits the needs and serves the goal of the attacker.
An extreme solution to the above mentioned problems would be to completely confine any downloaded executable content within the Web browser that is running it, hence not permitting any usage of the underlying system’s resources. Nevertheless, such a solution is not a feasible one since one grants access to system’s resources in order to make a program useful. By implication, one has to carefully consider what system resources and to what extent may be made available to a downloaded executable content, from within a browser, without endangering the system’s security and at the same time guaranteeing the usefulness of the executable content.
4. JAVA SECURITY
JAVA’s security model is focused on protecting users from hostile applets downloaded from untrusted sources across a network. To accomplish this goal, JAVA provides a customisable “sandbox” in which JAVA programs run. The sandbox is made up of several systems that range from the applet security manager to the basic features of the JAVA language and JAVA Virtual Machine. Within its “sandbox” the applet may do anything it wants but cannot gain access to the user’s file systems, network connections or other resources. For instance, an untrusted JAVA applet through its sandbox cannot perform any of the following actions:
· Read or write to the local disk
· Make a network connection to any host, except the one from which the applet came
· Create a new process
· Load a new dynamic library and directly call a native method.
Applets are loaded from the network by the applet Class Loader which receives the bytecode instruction stream and converts it into internal data structures that represent the applet’s classes. It then calls the verifier to check the class files, and creates a namespace where places all the applet’s classes. A unique namespace exists for each network source, thus preventing untrusted applets from gaining access to more privileged, trusted parts of the system. Applets downloaded from the net cannot create their own class loaders. Downloaded applets are also prevented from invoking methods in the system’s class loader.
The Class Loader invokes the Bytecode Verifier before running a newly imported applet. The verifier subjects each applet class to a number of tests: Checks the bytecode to ensure that it does not forge pointers, violate access restrictions or access objects using incorrect type information. Checks that class files have the correct format, parameters, arguments and return types are used correctly, ensures that stack overflow or underflow cannot occur, as well as any other actions needed to prove that the applet will not be allowed to corrupt part of the security mechanism or to replace part of the system with its own code.
The Security Manager is an abstract class that enforces the boundaries around the sandbox. Whenever an applet tries to perform an action which could corrupt the local machine or access information (like the above mentioned actions), the JVM first asks the security manager if this action can be performed safely. If the security manager approves the action, the virtual machine will then perform it. Otherwise, the virtual machine raises a security exception and writes an error message to the JAVA console. A web browser can only have one security manager. This assures that all access checks are made by a single security manager, thus enforcing a single security policy. The security manager is loaded at start-up and cannot be extended, overridden or replaced. For obvious reasons applets cannot create their own security managers.
JDK1.2 includes a set of new features (Gong, 1997a), (Gong, 1997b) which introduce another modus operandi for the Java security system. JDK 1.2 will consist of the following new protection mechanisms: security policy, access permissions, protection domains, access control checking, privileged operation and Java class loading and resolution.
The security policy introduced by JDK1.2 is instantiated at JVM startup and may be altered a posteriori via secure methods. It comprises of a mapping between properties of the running code (the URL of the code and the code signature) and a set of permissions granted to that code. If a piece of code carries more than one signatures then the permissions it is entitled to are computed as the sum of permission each signature is entitled to. An ASCII file containing the mappings between the applets and the permissions will be available. A future adjustment for the security policy is expected to be the inclusion of information such as user authentication and delegation.
There is a complete set of typed and parameterized access permissions contained in the JDK1.2 abstract class java.security.Permission. One of the most important methods in this class is the "implies" method. a.implies(b)=true means that if one is granted the permission a then it is also granted the permission b. Permissions may no longer be granted in JDK1.2 to classes but to protection domains. The latter consist of all the objects that correspond to a principal who has been authorised by the system.
Every class may belong to one domain only. The Java runtime maintains the mappings between classes and domains as well as between domains and permissions. It is possible to prevent the communication between different domains. When such a communication is necessary it may be performed either indirectly through system code, or directly if all the participating domains allow it. One of the future adjustments pertinent to the protection domains is the inclusion and usage of user authentication and delegation information, in order to be able for a piece of code to have different permissions when executed by different principals.
If a thread transverses more than one domain while executing, the permissions it is entitled to are computed based on the principle of least privilege. According to the latter, when the thread enters a domain which possesses fewer permissions then the previous, it is entitled to these rights, while when it enters a domain which possesses more permissions than the previous one, it is entitled to the permissions of the previous domain.
Until JDK1.1, the code that performed access controls had to know the status of all it's callers; these checks had to be performed by the programmer. JDK1.2 introduces a new class called AccessController which simplifies this process. A programmer may call the checkPermisssion method of this class, thus having the system itself perform the access control on behalf of the programmer. For backward compatibility reasons, the SecurityManager usage is still allowed.
There are cases when a piece of code wishes to use the permission it is entitled to itself, although the status of it's callers prohibit it. In such a case, the programmer may use the beginPrivileged and endPrivileged methods in the AccessController class and have his code use the aforementioned permissions. If in such a case the code calls another piece of code, the latter loses the privilege of the former.
The Classloader class has been replaced by the SecureClassloader. The latter can distinguish system classes from others and impose the designed security policy to the latter. In JDK1.2 policy restrictions apply both to applets and applications. In order to impose the security policy to locally installed applications too, a new class has been introduced, called java.security.Main.
As we have already mentioned, it is the purpose of Javasoft to include in following JDK revisions, user authentication information in the security policy. This will provide the means to run the code with different permissions, depending on who's behalf the code is running. User authentication information inclusion and usage has already been tested and performed to a certain degree (Balfanz, 1997a).
JDK1.2 and most of the emerging Java security frameworks applications depend on the existence of a public key infrastructure. It is an obvious necessity for these frameworks to support the widely accepted standards for PKI and for the security mechanisms that surround them, such as X.509v3 certificates, SSL, HTTPS, LDAPS, S/MIME.
5. EXTENSIONS AND IMPLEMENTATIONS
In analysing the effectiveness of the aforementioned JAVA security features, it is necessary to check whether there are adequate methods of controlling the most important assets of the system. Security manager performs the necessary checks to ensure that access to file system and access to network are well protected. Security manager is also responsible for access to control of threads as well as to environment variables and to any attempted system calls. JAVA language specification is responsible for the protection of random memory, while through JAVA libraries security checks can be added to input and output devices.
While many experts agree that the JAVA Security Model is basically sound, there is a concern that the model has not been examined in enough detail to ensure that the sandbox is as secure as is claimed. Because of this concern, many extensions of the JAVA security model and new security facilities have been proposed.
The JDK is the official JAVA implementation from Sun. The JDK 1.1 includes a new JAVA core API, built out of the java.security package that allows for digital signatures (authentication, integrity) and message digests, key management, certificate management and access control. The JAVA Cryptography Architecture refers to the framework for accessing and developing cryptographic functionality for the JAVA platform and encompasses nearly the entire JAVA security API. It was designed to provide implementation independence meaning that a new algorithm can be added later on without much difficulty and can be utilised in the same fashion as existing ones.
A concrete implementation of the JAVA security API is referred as a Cryptography Package Provider. JDK 1.1 comes with a default provider named “SUN” which includes an implementation of the NIST DSA algorithm, the MD5 and SHA message digest algorithms. JDK 1.1 provides a security tool, the javakey, whose primary use is to generate digital signatures for archive files (JAR files) which enable the packaging of class files. To sign an applet the producer first creates a JAR file and then creates a digital signature based on the contents of the JAR. Digitally signed applets can be promoted to trusted applets with few security restrictions.
Since the ability to encrypt the data prior to being transferred is very important, APIs for data encryption are contained in a JAVA Cryptography Extension, as an add-on package to JDK.
The central assumption in the security policy of previous JDK implementations was that all classes that resided on the local file system were considered to be more trustworthy than classes that had been loaded from the network. Therefore the locally loaded classes were not subject to the bytecode verifier. This was very dangerous because it destroyed an essential part of the low level security layers on which the higher level layers rely. Moreover, file access was controlled by Access Control Lists (ACLs) which provided a fairly good way to restrict access, but the implementation was unsatisfactory since they were the same for all applets on the system. Another problem was that users were typically not aware of the fact that local classes were considered to be more trustworthy than the ones loaded from the net. So they could download frequently used classes and add them to the local file system’s CLASSPATH of the JAVA applet viewer in order to access them more efficiently, which means that they automatically gave them “super-user” power without noticing.
JDK1.2 will provide solutions to most of these problems. All applets and applications are subject to the security policy and there is a fine-grained and extensible access control structure. Some browsers (e.g. Netscape Navigator) are already treating all classes as remote, loading them via classloaders.
Some important weaknesses are due to some arbitrary implementation choices that did not respect the spirit of JAVA semantics:
· Security manager’s default behaviour is to throw a security exception. However the user program may ignore the exception like any other, without the user noticing.
· There is no constraint to use a ready-made applet viewer with a JAVA enabled browser, which means that programmers are free to implement JAVA programs with their own security management policies.
· The runtime has no provision to check that the API classes are the original ones.
Recently, new policy enforcement methods, secure code distribution and Java firewall blocking methods have been found and some of them implemented. These are presented in the following paragraphs.
5.1 Policy enforcement methods
Once the code is authenticated to the system, that is associated with a principal, then the code is subject to the policy defined for that principal. To enforce this policy, three secure methods have been found (Wallach, 1997):
· Capabilities: Unforgeable pointers which can be safely given to user code
· Extended stack introspection: Information about the principals can be included in the stack
· Name space management: Restricting or changing an applet's namespace
5.1.1 Capabilities
Fundamentally, a capability is an unforgeable pointer to a controlled system resource. To use a capability, a program must have been first explicitly given that capability, either as part of its initialisation or as the result of calling another capability. Every top level class of an applet could be given by the system an array of capabilities (pointers to objects). Then the applet would be able to use whenever it wishes these capabilities. The objects that are referenced by the capabilities may implement and enforce their own, internal security policy, by checking the parameters with which they are called. The Java runtime would have to be modified in order to make private all the methods which handle system resources directly or indirectly. It is only the capabilities themselves (the referenced objects) that should have access to these methods.
Capabilities are easy to implement in Java, because of the underlying infrastructure. Systems that support "capabilities" have been researched. One of these is the Java Electronic Commerce Framework (Goldstein, 1996), which provides a security platform, complimentary to the one that JAVA is using right now, able to implement complex trust relationships between entities.
5.1.2 Extended stack introspection
This policy enforcement method has already been implemented in commercial browsers, such as Netscape Communicator 4 and Microsoft Internet Explorer 4 and in the JDK1.2. There are three primitives that must be implemented for this method:
· enablePrivilege(target)
· disablePrivilege(target)
· checkPrivilege(target).
Every system resource must be associated with a target.Before the system allows the use of a system resource, it should perform a checkPrivilege on the specified target. When a thread, associated with a principal, asks for a system resource it should perform an enablePrivilege on the specified target. The security policy will then decide whether that principal is entitled to use this target and the system will or will not grant the privilege to the code. After the thread has finished using this system resource it must execute a disablePrivilege. If the programmer omits the latter, the privilege should be discarded automatically. This can be done by storing the enabled privilege in a hidden and protected field of the method that created it The checkPrivilege primitive should check the stack and judge whether a privilege must be given or not based on the least privilege rule, in order to prevent trusted code from calling untrusted code and passing the latter the privileges of the former.
There are differences between the implementation of extended stack introspection by Microsoft and Netscape. One of them is that in the Microsoft implementation, only trusted code may define new targets, while in the Netscape implementation any code may define targets, in the form of (principal, string) pairs, where principal has to be the signer of the code who wishes to create the new target. Another difference is that the first recognises only one signature per code, while Netscape allows more than one signatures. Permissions are granted to code that has been signed by more than one signers based on the "consensus voting" rule, e.g. when the site administrator votes (designs security policy) for a signer to be able to use a system resource but the user does not know whether he should let the code signed by that signer access that system resource or not, the latter may vote "abstain". In this case, based on the consensus voting rule, the aforementioned code is allowed to use this system resource.
5.1.3 Name space management
It is a method to enforce a security policy by replacing or hiding the classes that are visible by a program. There has to be a mapping between the applets (and their respective signers) and the namespaces that each applet will be able to see. Hiding a class from the namespace means that the applet may not be able at alto use it, while replacing the class with another (possibly a subclass of the latter) provides a means for controlling even more the way that the applet will call and use the methods contained in the aforementioned class.
Let's assume that we created a subclass S of class C and a method M which overrides the respective method of class C. Method M of subclass S may be providing limited use of the resources that method M of class C provides normally to an applet. If we bind the name of S to C, then the applet that will call method M will have at it's disposal a limited, functional set of resources, although it will believe it has gained access to the full set of resources it has asked for.
5.2 Secure Code Distribution
Secure code distribution (Zhang, 1997) is one of the security issues that concern the Java community. There are various approaches to authentication for secure code distribution. One of them is the signed applets. The Java class file format is extensible. It is possible to add new attributes to the latter, without influencing the current structure or workflow of the classloaders. These new attributes can contain signatures for the applet which can be verified, provided that the user possesses the certificate of the entity who signed the applet. After the verification the security manager may grant certain rights to the applet, depending on the trustworthiness of the author or of the person who has signed the applet. The level of trust, and therefore the amount and species of rights that should be granted to the applet, that each user preserves for each applet author or signer can be defined a priori by forming a local security policy, accessible from the user through the browser and protected by all means available (e.g. filesystem rights) to the OS. Secure code distribution is already supported by Javasoft's JAR specification. A JAR is an archive encapsulating, with proprietary methods, signed or unsigned classes and other files (e.g. sounds).The signature can be verified by the JDK infrastructure, providing thus a secure authentication means for the distribution of applets.
One should not exclude the possibility of hostile code, deriving from a source or being signed by someone that a user considers to be "trusted". Furthermore, code signing provides no additional security layer for those applets that are considered to be "untrusted". They are still executed in the limited sandbox environment, and the local system's safety depends on the existing security infrastructure.
5.3 Confining the use of JAVA in a network domain
An organisation may wish to ban all Java incoming traffic from the Internet, but wishes also to deploy and use Java applets internally, in it’s own domain. This may be achieved by blocking the Java applets at the firewall (Martin, 1997). However it is a complex task and up to now no solution has proven to be complete, apart from locking all the browsers' preferences in the organisation’s internal domain in such a way so they will not be able to interpret Java. However, the latter would render the browsers incapable of interpreting Java while operating in the organisation’s internal domain too.
Blocking Java applets at the firewall can be performed by implementing a number of strategies in order to assure that applets do not penetrate the internal network, or if they do, they are not executed at all at the local machines. The first strategy should be the rewriting of the <applet> tag by a proxy, wherever this is found. It could be in an HTTP transmission, or in mail or news messages (HTML enabled mail and news clients exist in the market currently). Rewriting the <applet> tag will cause the client to ignore the existence of the java applet in the message. It should be mentioned though that Javascript may be used in order to create the <applet> tag just before the page is viewed in the browser, rendering the above blocking useless. Another strategy that must be implemented is the blocking of the CAFEBABE signature. Every Java class file begins with this 4-byte signature, (Sun, 1997c) so it is possible to block all java classes as soon as they reach the proxy. However, if SSL or JAR files are used, these countermeasures are rendered useless, since the <applet> tag or the CAFEBABE signature will pass undetected, through the proxy. In addition, another strategy that has to be implemented is to set the proxy to reject all files which have an extension ".class". However, if classes arrive at the firewall archived (JAR, Zip) the ".class" extension would not be detected.
If one decides to implement the aforementioned strategies, he should take under consideration the possibility of accidentally blocking useful information, e.g. files whose first 4-byte signature is CAFEBABE but are not Java classes or files that contain the "<applet>" string but do not call any Java applets (could possibly be a Java security paper, in HTML format) or even blocking files that end in ".class" but do not consist of Java classes.
6. PROPOSED ENHANCEMENTS
Native code can bypass all restrictions and directly access the underlying operating system (Venners, 1997). That flaw could be fixed by using digital signatures. The runtime system must have a native Class Loader and Security Manager that will impose specific restrictions and protections to the classes that are not certified as being secure and less drastic restrictions to the other classes. This native security manager will permit that JAVA applications can define their own security manager which will perform checks in complement to (and not instead of) those performed by the native Security Manager. The Security Manager could be much more flexible by enforcing different levels of control based on how much a particular publisher is trusted.
The runtime should provide a configurable audit system which would allow system administrators to study the circumstances under which each type of attack has been occurred. As a minimum, files read and written from the local file system should be logged, along with network usage.
Limiting system resources (degradation of service) is still an open issue. The Java community is not so concerned about it, though it is one of the easiest to exploit Java security leaks. The JDK should limit the level to which an applet may use system resources.
The security user interfaces we have witnessed so far demand too frequently from the user to take security-related decisions, based on security and system resources information he is provided with upon asked. The number of questions towards the user should be limited as much as possible. This can be achieved by having the site administrator define a system-wide policy (commercial browsers support already remote administration) and leave the user with a few questions to be asked. Asking the user too many questions sometimes presents an impact quite opposite than the one we wish. The user starts pressing “OK” to any question that comes up, either because he is tired of answering (“authorisation fatigue”) to all these questions or because he might not understand the nature of a security related question. The latter imposes new limits on the way that Java security providers have to ask questions to end users. These questions should be simple enough for an end user to understand, but at the same time they have to encapsulate in these all the security-related information that has to be contacted to the user. For instance, instead of asking the user whether he wishes to grant the permission to this word processing applet to open a system dictionary, use system fonts or grant write permission to the filesystem (at least to a directory of the filesystem), the question could be “Grant this application with word processing rights?”. Finally, privileges granted or denied to applets (signers) should be stored in order to be looked up automatically the next time an applet arrives that carries a signature by the same signer.
The few problems experienced by JAVA users to date can be classified as implementation defects, rather than inherent flaws in the security model itself. Nonetheless, users and system administrators should adhere to the following guidelines to enhance their Internet experience:
· The best defence against security problems is staying informed. One way is to visit Sun’s JAVA Security Frequently Asked Questions (FAQ) (http//java.sun.com/sfaq). Another way is to become familiar with CERT (http://www.cert.org), an organisation which provides assistance to individuals and organisations that are experiencing security attacks.
· Use the most current version of all networking software - particularly browser programs.
· Employ firewalls as security measures. As JAVA becomes even more pervasive, corporate users who rely on firewalls as a first line of defence are going to demand more JAVA policies built into their firewalls. Commercial firewall developers are rapidly releasing modern products that offer the techniques in various combinations.
· Remain vigilant and investigate even the smallest anomalies. A “missing file” might really be the result of a “hack”.
· Be cautious of the web sites you visit. You never know what you might be downloading.
7. CONCLUSIONS
Remote execution of code has been an attractive and popular approach. JAVA programming language gave birth to a revolution in the programming world three years ago with nine adjectives; the third one was Secure. With the JavaSecurity API, JAVA 1.1 is building on the foundation of previous versions and afford us more flexibility to do what we want, even though it is widely accepted that security, unfortunately but not surprisingly, can never be completely guaranteed.
JDK1.2 includes a set of new security features and protection mechanisms (Gong, 1997a), (Gong, 1997b), such as security policy, access permissions, protection domains, access control checking, privileged operation and Java class loading and resolution. SSL functionality is being incorporated in Java, while the use of X.509 certificates and the interoperability with Directories, through the Java Naming and Directory Interface (JNDI), is already supported. These new features are expected to form a robust security scheme, highly interoperable with other security schemes already deployed in enterprises. The deployment of such security schemes depends on the services delivered by Trusted Third Parties (TTP).
A fundamental research topic (McGraw, 1996) is a new approach to the way the Access Control List model works. The perspective idea is to provide a secure and safe way to implement mature Remote Method Invocation (RMI) facility. RMI will be possible with a strong ACL system in place. Furthermore, RMI already supports encrypted communication, through the use of SSL (Sun, 1998). Another future main security goal would be the design and implementation of security features directly into the Object class itself.
Downloadable executable content security and especially JAVA security is an ongoing concern; thus must be continually reviewed to ensure it is still appropriate and effective, but the researchers must always have in mind what W. Diffie says: "... the only good locks are open, public, and accessible ones".
8. REFERENCES
(Balfanz, 1997a) D.Balfanz, L.Gong, (1997) "Secure Multi-Processing in Java".
(Felten, 1997) E.W.Felten, D.Balfanz, D.Dean, D.S.Wallach, (1997) "Web Spoofing: An Internet Con Game", Proceeedings of the 20th National Information Systems Security Conference.
(Goldstein, 1996) Goldstein T., (1996) The Gateway Security Model in the Java Electronic Commerce
Framework, JavaSoft, available at http://www.javasoft.com/products/commerce/jectf_gateway.ps
(Gong, 1997a) L.Gong, M.Mueller, H.Prafullchandra, R.Schemers, (1997) "Going Beyond the Sandbox: An Overview of the New Security Architecture in the Java Development Kit 1.2", Proceedings of the USENIX Symposium on Internet Technologies and Systems.
(Gong, 1997b) L.Gong, (1997)"New Security Architectural Directions for Java", Proc. of IEEE COMPCON.
(Gritzalis, 1991) Gritzalis D., (1991) Information Systems Security, GCS Publications (in Greek).
(Martin, 1997) Martin D., Rajagopalan S., Rubin A., (1997) Blocking Java Applets at the Firewall, Proceedingsof the SNDSS 1997 Symposium on Network and Distributed System Security, pp.123-133, IEEE Computer Society Press.
(McGraw, 1996) McGraw G., Felten E., (1996) Java Security Hostile Applets, Holes and Antidotes, J. Wiley & Sons Inc.
(Sterbenz, 1996) Sterbenz A., (1996) “An Evaluation of the Java Security Model”, Proceedings of the 12th Computer Security Applications Conference.
(Sun, 1997a) Sun Microsystems, (1997) Frequently Asked Questions - Applet Security, at
http://java.sun.com/sfaq/
(Sun, 1997b) Sun Microsystems, (1997) Secure Computing with Java: Now and the Future, at
http://java.sun.com/marketing/collateral/security.html
(Sun, 1997c) The Java Virtual Machine Specification, (1997) available in the Web at
http://java.sun.com/docs/books/vmspec/
(Sun, 1998) Sun Microsystems, (1998) Java Remote Method Invocation - Distributed computing for Java, at
http://java.sun.com:81/marketing/collateral/javarmi.html
(Venners, 1997) Venners B., (1997) Java’s security architecture, at
http:// www.javaworld.com/javaworld/jw-08-1997/jw-08-hood.html
(Wallach, 1997) D.S.Wallach, D.Balfanz, D.Dean, E.W.Felten, (1997) "Extensible Security Architectures for Java", Proceedings of the 16th Symposium on Operating Systems Principles.
(Yellin, 1995) Yellin F., (1995) Low Level Security in Java, at http: //java.sun.com/sfaq/verifier.html
(Zhang, 1997) X.N.Zhang, "Secure Code Distribution", (1997) IEEE Computer.
9. BIOGRAPHIES
Stefanos Gritzalis received a BSc in Physics and an MSc in Electronic Automation, both from the University of Athens, Greece. He is also pursuing a PhD degree on Distributed Systems Security, with the Department of Informatics of the University of Athens. Currently, he is an Assistant Professor with the Department of Informatics of the Technological Educational Institute (TEI) of Athens, and a Research Associate with the Department of Information & Communication Systems of the University of the Aegean, Greece. He has been involved with many national and EU funded R&D projects in the areas of Computer Security and Distributed Systems and he has authored two books (in Greek) and more than 10 technical papers and international conference presentations. His research interests include Distributed Systems, Computer Systems Security, and Operating Systems.
John Iliadis is pursuing his thesis statement with the Department of Informatics of the Technological Educational Institute (TEI) of Athens, Greece. He is also an Assistant Researcher at the Department of Information & Communications Systems of the University of the Aegean, Greece. His research interests include Computer Systems Security and Distributed Systems.
Vasiliki Oikonomou holds a BSc in Physics from the University of Thessaloniki, Greece, and an MSc in Electronic Automation, from the University of Athens, Greece. She is also pursuing a PhD degree on Component-based Software Systems, with the Department of Informatics of the University of Athens. Currently, she is an Assistant Professor with the Department of Informatics of the Technological Educational Institute (TEI) of Athens. Her research interests include Component-based Software Systems, and Portable software over Computer Networks.