Vijay Saraswat. Java is not type-safe. http://matrix.research.att.com/vj/bug.html, 1997.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....interpretation is that the reference types used by the algorithm consist of names only. This is correct as long as there is an intended disambiguation of names, accompanied by mechanisms to ensure consistent disambiguation between methods that exchange objects. Consider the following example [5,8]. A method m 1 has an argument of type C, whose disambiguation in m 1 is a class c (identified by the name C plus some loader) Another method m 2 calls m 1 , passing an object of type C to it. If C is disambiguated to a class c # in m 2 ,itmustbec c # ; otherwise, type safety could be broken. ....

....object of type C to it. If C is disambiguated to a class c # in m 2 ,itmustbec c # ; otherwise, type safety could be broken. In the first edition of JS, these issues were not mentioned. Type safety bugs due to inconsistent disambiguation of names were found in earlier implementations of the JVM [8]. Those bugs were corrected by the introduction of loading constraints [9] described in JS5. Loading constraints ensure that classes exchanging objects agree on the actual classes of the exchanged objects, not only on their names. Loading constraints are external to bytecode verification; they ....

[Article contains additional citation context not shown here]

Saraswat V. Java is not type-safe. Technical Report, AT&T Research, 1997. http://www.research.att.com/vj/bug.html.

....and occasional use of actual classes guarantee type safety only under certain assumptions. Examples of these assumptions are the loading constraints introduced in the Java 2 Platform [9,11] to avoid the type safety problems arising precisely because of the violation of the assumptions they enforce [12]. Simply stated, loading constraints ensure that classes exchanging objects (through their methods and fields) agree on the actual types (i.e. not only on the FQNs but also the loaders) of such objects. As it turns out, the loading constraints introduced in [9,11] do not cover all the assumptions ....

....components of the JVM. With SDK 1.3, a security exception is thrown, because of restricted access to the java.lang package. This choice may be reasonable if a unique hierarchy and unique system classes are meant for any JVM. There are arguments in favor of a more liberal notion (as mentioned in [12]) in which system classes and multiple class hierarchies may be user definable. In any case, the issue of system classes certainly deserves further explanation and clarification in future editions of [9] If we assume a single class hierarchy (and therefore a single java.lang.Object class) an ....

[Article contains additional citation context not shown here]

Saraswat V. Java is not type-safe. Available at http://www.research.att.com/vj/bug.html [1997].

....of FQNs and occasional use of actual classes guarantee type safety only under certain assumptions. Examples of these assumptions are the loading constraints introduced in the Java 2 Platform [6, 5] to avoid the type safety problems exactly arising from the violation of the assumptions they enforce [9]. Simply stated, loading constraints ensure that classes exchanging objects (through their methods and fields) agree on the actual types (and not only on the FQNs) of such objects. As it turns out, loading constraints do not cover all the assumptions needed to guarantee type safety. An example ....

Vijay Saraswat. Java is not type-safe. Technical report, ATgcT Research, 1997. http://www. research. att. com/vj/bug. html.

....implements interface C, which defines an operation use t(t) 6. Module mD links against modules mB and mC. It may thus call C.use t(B.get t( passing a value of type integer to a routine expecting a value of type string. This constraint is related to the requirement to prevent bridge classes [Saraswat97] in Java from creating similar type system violations. Verification: The bytecode in the module must be shown to conform to the interfaces which it imports exports, and to respect any typing constraints associated with the language in which it is written, using techniques such as those presented ....

Vijay Saraswat. Java is Not Type-Safe. http://www.research.att.com/ ~vj/bug.html, August 1997. (p 112)

....system (HIS 635 GCOS III) based on the ability to execute a user s array contents with an assigned GOTO statement in Fortran [1] The statement can misinterpret its target, the contents of an arbitrary integer variable, as an instruction. Today we see the same sort of problem in a di erent context [29]. 2.1 Type Preservation An important property related to type safety is the idea of type preservation. Type preservation is frequently confused with type soundness in the literature. Soundness is a statement about the progress a program s execution can make if the program is well typed. Type ....

Vijay Saraswat. Java is not type-safe. Unpublished manuscript. Available at www.research.att.com/~vj/bug.html., 1997.

....that the unit satisfies a particular signature. This type checking must be performed in the correct context to ensure that dynamic linking is type safe. Java s dynamic class loading is broken because it checks types in a type environment that may differ from the environment where the class is used [74]. 36 fun registerLoader(format:str, loader:db Thetafile void) Delta Delta Delta fun addLoader(format:str, aLoader) registerLoader(format, invoke aLoader numInfo:int info error:str void :db Thetafile void 6 Figure 3.7 : Dynamic linking with invoke 3.3 Possible Extensions ....

Saraswat, V. Java is not type-safe, August 1997. www.research.att.com/vj/bug.html.

....embed class names to embed classes instead, namely New , Init and Class . The function that checks compatibility is refined to have the following signature: compat : Class Theta Class Bool , whose suitable use (see the Rules below) guarantees that type spoofing problems as detected by Saraswat [22] do not occur in our model. 43 Fig. 18 Execution of refined rules execVM redef = case code(pc) of GetStatic(f ) if cinitd( d cNm(f ) then opd : opd Delta glo( b f ) pc : pc 1 else callLink(cLd(meth) cNm(f ) switchVM redef = if switch = Yield(res) then if ....

....in the correctly started dynamic VM no instruction can be executed with operands which do not belong to its (dynamically) determined name space. As a corollary of this theorem we can also show, using a similar argument as used in [16] that the class loading bug, which was detected by Saraswat [22], does not occur in our model. 6 Related and Future Work The trustful VM, our starting machine described in Sect. 2 and similar to the machine defined in [3] as target machine for the compilation of Java Programs, is a high level stack machine. It directly supports bytecode instructions for ....

[Article contains additional citation context not shown here]

V. Saraswat. Java is not type-safe. Web pages at: http://- www.research.att.com/~vj/main.html, 1997.

....and occasional use of actual classes guarantee type safety only under certain assumptions. Examples of these assumptions are the loading constraints introduced in the Java 2 Platform [6, 5] to avoid the type safety problems arising precisely because of the violation of the assumptions they enforce [10]. Simply stated, loading constraints ensure that classes exchanging objects (through their methods and elds) agree on the actual types (i.e. not only on the FQNs but also the loaders) of such objects. As it turns out, the loading constraints introduced in [6, 5] do not cover all the assumptions ....

....components of the JVM. With SDK 1.3, a security exception is thrown, because of restricted access to the java.lang package. This choice may be reasonable if a unique hierarchy and unique system classes are meant for any JVM. There are arguments in favor of a more liberal notion (as mentioned in [10]) in which system classes and multiple class hierarchies may be user de nable. In any case, the issue of system classes certainly deserves further explanation and clari cation in future editions of [6] If we assume a single class hierarchy (and therefore a single java.lang.Object class) an ....

[Article contains additional citation context not shown here]

Vijay Saraswat. Java is not type-safe. Technical report, AT&T Research, 1997. Available at http://www.research.att.com/vj/bug.html.

....correct implementation. Goldberg [4] directly used data flow analysis to formally specify bytecode verification focusing on type correctness and global type consistency for dynamic class loading. He successfully formalized a way to relate bytecode verification and class loading. Saraswat [14] studied static type (un)safety of JAVA in the presence of more than one class loader. We do not consider class loaders in this paper. The Kimera project [15] was quite effective in detecting flaws in commercial bytecode verifiers. Using a comparative testing approach, they wrote a reference ....

Saraswat, V. Java is not Type-safe. AT&T Research Tech. Rep., 1997. .

....programs during their execution. As a result, the reader can run experiments by executing Java programs on our Java machine, compiling them to bytecode and executing that bytecode on our JVM machine. For example, it can be checked that our Bytecode Verifier rejects the program found by Saraswat [30]. The CD contains the entire text of the book, numerous examples and exercises which support using the book for teaching, the sources of the executable models, and the source code for AsmGofer together with installation instructions (and also precompiled binaries of AsmGofer for several popular ....

V. Saraswat. Java is not type-safe. Technical report, AT&T, Research, 1997. http://www.research.att.com/~vj/bug.html.

....to determine, prior to execution, the actual loader of a class because loaders can delegate class loading to each other according to the program logic of user written code. On the other hand, loading a class before it is required for execution is undesirable. Saraswat rst publicly reported [17] name spoo ng problems due to de ciencies in the mechanisms employed by earlier versions of the JVM. A. Goldberg s current aliation and address: Shoulders Corp. 800 West El Camino Real, Mountain View, CA 94040. The Sun solution [14] to such problems employs a constraint mechanism. ....

....cannot determine what the class the name T denotes, until the name T is actually resolved in class D. In fact, if the class were loaded at the time when the n(T t) method is invoked, the JVM would be able to detect that the value does not conform to the loaded class. The bug reported by Saraswat [17] led to type violations in earlier versions of the JVM. In reference to the example in Figure 1, the earlier versions of 2 The JVM speci cation allows loading of a class to happen at any time no later than its rst active use. In this example, we assume that loading of a class happens exactly at ....

[Article contains additional citation context not shown here]

V. Saraswat. Java is not type-safe. Technical report, AT&T Research, 1997. http://www.research.att.com/~vj/bug.html.

....of type C to it. If C is disambiguated to a class c 0 in m 2 , it must be the case that c = c 0 . Otherwise, type safety could be broken. In the rst edition of JS, these issues were not mentioned. Type safety bugs related to these issues were found in earlier implementations of the JVM [Sar97, DFW96]. Those bugs were corrected by the introduction of loading constraints [LB98] described in JS5. Loading constraints ensure that classes exchanging objects, through methods and elds, agree on the actual classes of these objects, not only on their names. Loading constraints are external to ....

Vijay Saraswat. Java is not type-safe. Technical report, AT&T Research, 1997. Available at http://www.research.att.com/vj/ bug.html.

....of FQNs and occasional use of actual classes guarantee type safety only under certain assumptions. Examples of these assumptions are the loading constraints introduced in the Java 2 Platform [6, 5] to avoid the type safety problems exactly arising from the violation of the assumptions they enforce [9]. Simply stated, loading constraints ensure that classes exchanging objects (through their methods and elds) agree on the actual types (and not only on the FQNs) of such objects. As it turns out, loading constraints do not cover all the assumptions needed to guarantee type safety. An example ....

Vijay Saraswat. Java is not type-safe. Technical report, AT&T Research, 1997. http://www.research.att.com/vj/bug.html.

.... executed rather than source code, and as bytecode is not always the product of compilation, Java security lies primarily with the bytecode verifier, which was formalized as as a type inference system where stack locations have types on a per instruction basis, 22, 11, 10, 19] On the other hand, [21] reported security flaws due to inconsistencies between loaders, which were rectified in later releases, as described in [17] An operational semantics for multiple loaders is given in [14] Thus, various components of Java and the virtual machine have been studied at considerable depth in ....

Vijay Saraswat. Java is not type-safe. Technical report, AT&T Rresearch, 1997. http://www.research. att.comp/ vj/bug.html.

....accessible only within their definition package. This combination of features inevitably leads to complexities and uncertainties which can have unfortunate consequences in terms of security. This is manifested by the fact that apparently harmless programs can lead to unexpected security flaws [12]. Furthermore some features of the informal specification of the language and the virtual machine are subject to different interpretations. This situation is clearly not acceptable for a language in which security is such an important issue and we believe that the only way to tackle these ....

....we do not describe type checking either. We consider it as a complementary issue which can be tackled e.g. by using the system presented by Qian in [11] Then we show that this formalisation allows us to expose in a straightforward way a security problem that was discovered empirically in [12]. It is assumed that the reader is familiar with Java and its terminology concerning classes, interfaces, and visibility modifiers. The next section summarises our notation for these entities. Irisa Security and Dynamic Class Loading in Java: A Formalisation 5 2 Syntax Below we formalise the ....

[Article contains additional citation context not shown here]

V. Saraswat. Java is not type-safe. Technical report, AT&T Research, 1997. http://www.research.att.com/vj/bug.html.

....no need for objects in different name spaces to be in the same heap [19] There is an important exception to this rule. Java s system classes (e.g. java.lang. loaded by the null class loader, are shared; thus, static variables in system classes are visible to every name space on the system [34]. Thus, we put system classes into a system heap , visible to all name spaces 3 . As a first level approximation, classes in the system heap are trusted and loaded off the local file system or any other trusted path; classes loaded in the private heap are untrusted and their memory resources are ....

..... If the referred object was collected by the garbage collector, this event would not be visible to the reference in the referring heap. In that case, when a reference was made after the collection, the results would be unpredictable. A cross reference could be established via a bridge class [34]. A bridge class is a class accessible from more then one name space. Any system class could potentially play the role of bridge classes. In Figure 2, a reference is stored in a system class shared by all name spaces, and a reference to an object in name space A is copied into name space B. When ....

V Saraswat. "Java is Not Type-Safe". URL: http://www.research. att.com/~vj/main.html. 1997.

....elements of arrays. 2.2 Reference Types There are four kinds of reference types: classes, arrays, interfaces and the type null, the type with a single value, the reference null. Each object and interface type is uniquely named by its fully qualified name together and the name of its class loader [S97]. For the purposes of this paper, the structure of the name space of classes is not relevant. Thus the collection of class names is denoted by an abstract set N. Should this paper be extended to check access constraints implied by the protected attribute, then the package structure of the name ....

....However, there is not much gained in doing so because invoking an interface method requires a search of the method table of the this pointer s object class. The type test corresponds to searching the table but not finding a name signature match. Saraswat in his paper Java is not type safe [S97] describes a bug in the JVM due to class name spoofing. It suggests that a formal specification of namespaces management and loading, particularly in a mutithreaded environment, should be pursued. Dean initiated such a study in [D97] The Kimera project [K97] has uncovered bugs in the JVM using ....

Saraswat, V. "Java is not type safe," http://www.research.att.com/~vj/bug.html

....the JVM instructions. Here, we abstract from several details, as for example the resolution of symbolic references. These aspects will be added in further refinement steps of our formalization. We also do not yet consider dynamic class loading, which revealed to introduce a problem of type safety [Sar97]. 1.2 Related Work Cohen [Coh97] has implemented in ACL2 a so called defensive JVM, where runtime checks are performed to guarantee a type safe execution of the code. In contrast, our approach does not do type checking at runtime. To assure a type safe execution, we need to check the code before ....

Vijay Saraswat. Java is not type-safe. . http://www.research.att.com/~vj/main.html, August 1997.

....linker loader [4, 5, 23] The semantics of the Java source language [7, 35, 37, 27, 1, 29, 8] the Java bytecode [33, 12, 28, 26, 29] and safety pitfalls or security considerations [4, 24, 5, 38, 23] has attracted much research. In some cases, this research has helped to get some loopholes xed [32]; in other cases, it has illuminated grey areas and explored possible interpretations [12, 35, 9, 33, 11] This paper presents a further stage in our ongoing research into the semantics of the Java language. Java was designed with the aim to be conservative in its inclusion of new language ....

Vijay Saraswat. Java is not Type-Safe. Technical report, AT&T Rresearch, 1997. http://www.research. att.comp/~vj/bug.html.

....[10] to the Java platform, and JavaBeans [8] components. Despite the increasingly important role of class loaders, the underlying mechanism has not been adequately described in the literature. A further contribution of this paper is to present a solution to the long standing type safety problem [20] with class loaders. Early versions (1.0 and 1.1) of the JDK contained a serious flaw in class loader implementation. Improperly written class loaders could defeat the type safety guarantee of the Java virtual machine. Note that the type safety problem did not impose any immediate security risks, ....

....in section 2 performs a lookup in the loaded class cache. 4.2 Namespace Consistency among Delegating Loaders We now describe the type safety problems that can arise with delegating class loaders. The problem has been known for some time. The first published account was given by Vijay Saraswat [20]. Notation 4.1 We will represent a class type using the notation hC; Ldi L i , where C denotes the name of the class, Ld denotes the 5 class s defining loader, and L i denotes the loader that initiated class loading. When we do not care about the defining loader, we use a simplified notation ....

[Article contains additional citation context not shown here]

Vijay Saraswat. Java is not type-safe. available at http://www.research.att.com/vj/bug.html, 1997.

No context found.

Vijay Saraswat. Java is not type-safe. http://matrix.research.att.com/vj/bug.html, 1997.

No context found.

Vijay Saraswat, Java is not type-safe, Web pages at: http://www.research.att.com/~vj/main.html, 1997.

No context found.

Vijay Saraswat. Java is not type-safe. Technical report, AT&T Rresearch, 1997. http://www.research. att.comp/ vj/bug.html.

No context found.

Saraswat, V.: Java is not type-safe. (1997)

No context found.

Vijay Saraswat. Java is not type-safe. Technical report, AT&T Rresearch, 1997. http://www.research. att.comp/vj/bug.html.

First 50 documents

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