McGraw, G., Felten E.W. Java Security: Hostile Applets, Holes, and Antidotes. John Wiley and Sons, 1996  Home/Search   Document Not in Database   Summary   Related Articles   Check

....on the victim s machine, or otherwise abuse other resources available from that machine. Moreover, mobile code sandboxes intended to constrain mobile code have in many cases proven unsatisfactory, in that implementation errors enable mobile code to circumvent the sandbox s security mechanisms [2, 10]. One of the oldest ideas in security, computer or otherwise, is to physically separate the attacker from the resources of value. In this paper we present a novel preprint of paper to appear in 1998 IEEE Symposium on Security and Privacy, May 1998, Oakland, California. approach for physically ....

....types of attack that applets can mount, and describe the extent to which our system defends against them. Accessing and modifying protected resources Several bugs in the type safety mechanisms of Java have provided ways for applets to bypass Java sandboxes, including some in popular browsers [2, 10]. These penetrations typically enable the applet to perform any operation that the operating system allows, including reading and writing the user s les and opening network connections to other machines to attack them. We anticipate that in the foreseeable future, type safety errors will continue ....

G. McGraw and E. W. Felten. Java Security: Hostile Applets, Holes, and Antidotes, John Wiley & Sons, 1997.

....that executes them. In both cases code that comes from an outside source is executed on the receiver s site, has the receiver s access permissions and possibly can harm the site s integrity, security, and privacy. Agents and pushlets introduce four basic categories of potential security threats [23, 58, 109, 110]: Leakage: unauthorized attempts to obtain information belonging to or intended for someone else Tampering: unauthorized changing (including deleting) of information Resource stealing: unauthorized use of resources or facilities (e.g. memory, disk space) Antagonism: interactions not resulting ....

G. McGraw and E. W. Felten. Java security: hostile applets, holes, and antidotes. John Wiley, New York, 1997.

....such a way that a user will be able to upload a model file and view it in GUI. Due to security issues, applets are not allowed to access the local hard disk [24] To circumvent this security restriction imposed by browsers as well as Java Virtual Machine (JVM) user needs to install a policy file [25] (as currently used for UCWaves) or to purchase a commercial security certificate service. b) The Policy File. One way the Java platform provides protection from attack of a virus is through the use of a security manager. Currently Java Development Kit (JDK) system code invokes security manager ....

McGraw G, Felten E. Java security hostile applets, holes, and antidotes. New York: Wiley; 1999.

....web. At the same time, the impact of extensibility on overall system security and specifically access control is still ill understood. And, the protection mechanisms in these extensible systems are rudimentary at best, as illustrated by the continuous string of security breaches in the Java system [4, 15]. Mainstream operating and file systems use access control mechanisms that are familiar and widely accepted by users. Their use of individuals and groups in combination with fully featured access control lists has the potential to offer a flexible and powerful mechanism to protect files and other ....

....above, i.e. the decision which services of the system a given extension can utilize and which interfaces it can extend, must be carefully controlled. However, access control in existing extensible systems is rudimentary at best. 1. 2 The State of Affairs The current Java security model [8, 15] distinguishes between trusted extensions (code stored on the local file system) which have access to the full functionality of the Java system, and untrusted extensions (all remote code) Untrusted extensions are placed into a so called sandbox which limits extensions from using some system ....

[Article contains additional citation context not shown here]

Gary McGraw and Edward W. Felten. Java Security: Hostile Applets, Holes and Antidotes. Wiley Computer Publishing, John Wiley & Sons, Inc., New York, New York, 1997.

....security on the client s machine, but it includes no defenses against denial of service attacks directed against computing resources such as memory and CPU. Six years after Java was first released to the public in 1995, industrial browsers still do not withstand even the simplest of these attacks [58]. As a result, browsers stop responding to user requests and, in some cases, even crash. Java has also become popular for many server side applications. For instance, servlets are small programs that provide dynamic content to users, such as Java Server Pages [7] Often, a server hosts many ....

McGraw, G., and Felten, E. Java Security: Hostile Applets, Holes, and Antidotes. Wiley Computer Publishing. John Wiley and Sons, New York, NY, January 1997.

....the run time system, again adding complexity to the task of analyzing the veri cation logic. In the program understanding literature, it is well known that interleaving and delocalized program plans lead to programs that are dicult to comprehend [49, 38] This so called scattershot security [41] adds considerable complexity to the task of implementing, validating and maintaining a reliable veri er. Nevertheless, one may understand the rationale for current JVM architectures by considering the need to accommodate a lazy, dynamic linking strategy. Such a strategy seeks to defer expensive ....

Gary McGraw and Edward W. Felten. Java Security: Hostile Applets, Holes, and Antidotes. John Wiley & Sons, Inc, 1997.

....on the victim s machine, or otherwise abuse other resources available from that machine. Moreover, mo bile code sandboxes intended to constrain mobile code have in many cases proven unsatisfactory, in that implementation errors enable mobile code to circumvent the sandbox s security mechanisms [1, 9]. One of the oldest ideas in security, computer or otherwise, is to physically separate the attacker from the resources of value. In this paper we present a novel approach for physically separating mobile code from those resources. The basic idea is to execute the mo bile code somewhere other ....

....classes of attack that applets can mount, and describe the extent to which our system defends against them. Accessing and modifying protected resources Several bugs in the type safety mechanisms of Java have provided ways for applets to bypass Java sandboxes, including some in popular browsers [1, 9]. These penetrations typically enable the applet to perform any operation that the operating system allows, including reading and writing the user s files and opening network connections to other machines to attack them. We anticipate that in the foreseeable future, type safety errors will ....

G. McGraw and E. W. Felten. Java Security: Hostile Ap- plets, Holes, and Antidotes, John Wiley &: Sons, 1997.

....referred to the literature [12] A smart card is a secure token that may control commodities of real value. Secure here means that the card should be hardware and software tamper resistant, and that it should not leak information. The considerations that apply to the security of Java in general [8] also apply to Java for smart cards. In addition Java for smart cards should provide facilities such as ownership control and cryptographically protected modes of use. The resource limitation of a smart card makes it more difficult to ensure that security is maintained. For example currently a ....

G. McGraw and E. W. Felten. Java security: Hostile applets, holes and antidotes. John Wiley & Sons, Chichester, England, 1997.

....for users to execute applets from unknown sources on their computers. One such restriction is that applets are usually only allowed to open a network connection to the host from which the applet was downloaded. A number of problems with Java security have been discovered by various researchers [5] [7]. Java could also be applied to performing a distributed computation. Java s straightforward support for networking and multiple threads of execution make construction of an applet to perform the computing tasks simple. The possibility of using Java applets to covertly or otherwise perform a ....

Gary McGraw and Edward W. Felten. Java Security: Hostile Applets, Holes, and Antidotes. John Wiley & Sons, Inc., 1997.

....require us to solve a whole new set of problems that researchers have just recently started to address. In this section we focus our attention to work that is directly related to ours. There are several methods for intrusion prevention in operating systems, ranging from type safe languages [15, 17, 25, 8, 7], fault isolation [23] and code veri cation [19] to operating system speci c permission mechanisms [16, 21] and system call interception [2, 5, 6, 1] Capabilities and access control lists are the most common mechanisms operating systems use for access control. Such mechanisms expand the UNIX ....

....life, making it impossible for malicious objects to escape. The methods that we mentioned so far rely on the operating system to provide with some sort of mechanism to enforce security. There are, however, approaches that rely on safe languages, 15, 22, 14, 9] the most common example being Java [17]. In Java applets, all accesses to unsafe operations must be approved by the security manager. The default restrictions prevent accesses to the disk and network connections to computers other than the server the applet was down loaded from. Our system is not only restricted to a limited set set of ....

Gary McGraw and Edward W. Felten. Java Security: hostile applets, holes and antidotes. Wiley, New York, NY, 1997.

.... has recently reported a bug in the way in which the JVM determines whether two classes are equivalent [12] This bug can be exploited to cause type confusion between two classes with the well known consequences for the security such as providing access to private variables from other classes [9]. Consider the following four class files cf R1 ; cf R2 ; cf RR ; cf RT of code, all of whose superclass is java.lang.Object: Class file : cf R1 Class file : cf R2 class R class R private int i = 1 public int i = 1 Class file : cf RR Class file : cf RT class RR class RT R getR( private R r ....

G. McGraw and E. Felten. Java Security: hostile applets, holes and antidotes. J. Wiley & Sons, 1997.

....of that program. Although above two solutions have an effect of discouraging the program theft, they are not enough strong for the protection of Java programs. 3. 2 Digital Certificate for Java Applet Java security model provides us an authentication mechanism known as a concept of signed applet[16][23] A sign (called digital certificate) related with an applet indicates, who is the true developer of that applet, just like a watermark does. A user who has downloaded a signed applet can know whether it is worthy reliable or not by checking the sign. The sign also guarantees that the applet ....

McGraw, G. and Felten E., Java security: hostile applets, holes, and antidotes, John Wiley & Sons, 1997.

....result in violation of [expected] policies. Detailed analysis of the factors that contribute to the existence of these vulnerabilities is mostly limited to cryptic articles posted to hacker newsgroups or web sites. There are a few notable exceptions [Lin75, Spa89a, Spa89b, Sto90, Kum95, DFW96, MF97, DW95] and this report attempts to add to these with a detailed analysis of five common computer vulnerabilities. The analysis of each vulnerability attempts to identify its characteristics, the [expected] policies violated by its exploitation, and contributes to the understanding of the steps ....

Gary McGraw and Edward W. Felten. Java Security: Hostile Applets, Holes and Antidotes. John Wiley & Sons, Inc., 1997.

No context found.

McGraw, G., Felten E.W. Java Security: Hostile Applets, Holes, and Antidotes. John Wiley and Sons, 1996

No context found.

Gary McGraw and Edward W. Felten. Java Security: Hostile Applets, Holes, and Antidotes. John Wiley & Sons, Inc, 1997.

No context found.

Gary McGraw and Edward W. Felten. Java Security: Hostile Applets, Holes and Antidotes. John Wiley and Sons, 1996.

No context found.

Dr. Gary McGraw and Professor Ed Felten. Java Security: Hostile Applets, Holes and Antidotes. John Wiley and Sons, 1997. ISBN: 0-4711-7842-X.

No context found.

Gary McGraw and Edward W. Felten. Java Security: Hostile Applets, Holes, and Antidotes. John Wiley and Sons, New York, New York, 1997.

No context found.

Gary McGraw and Edward W. Felten. Java Security: Hostile Applets, Holes and Antidotes. Wiley Computer Publishing, John Wiley & Sons, Inc., New York, New York, 1997.

No context found.

Gary McGraw and Edward W. Felten. Java Security: hostile applets, holes and antidotes. Wiley, New York, NY, 1997.

No context found.

G. McGraw and E. W. Felten. Java Security: hostile applets, holes and antidotes. Wiley, New York, NY, 1997.

No context found.

Gary McGraw and Edward W. Felten. Java Security: hostile applets, holes and antidotes. Wiley, New York, NY, 1997.

No context found.

McGraw, Gary and Felten, Edward W. (1997). Java Security: hostile applets, holes and antidotes. Wiley, New York, NY.

No context found.

Gary McGraw and Edward W. Felten. Java Security: Hostile Applets, Holes, and Antidotes. Wiley, 1997.

No context found.

Gary McGraw and Edward W. Felten. Java Security: Hostile Applets, Holes, and Antidotes. Wiley, 1997.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC