| Wiki Markup |
|---|
In a JVM, "Two classes are the same class (and consequently the same type) if they are loaded by the same class loader, and they have the same fully qualified name" \[[JVMSpec 1999|AA. Bibliography#JVMSpec 99]\]. A class with the same name but a different package name is different, and a class with the same fully qualified name but which has been loaded by a different class loader is also different. |
It may could be necessary to check whether a given object has a specific class type or whether two objects have the same class type associated with them, for example, when implementing the equals() method. If the comparison is performed incorrectly, the code might could assume that the two objects are of the same class when they are not.
Depending on the function that the insecure code performs, it may could be vulnerable to a mix-and-match attack. An attacker may could supply a malicious class with the same fully qualified name as the target class. If access to a protected resource is granted based on the comparison of class names alone, the unprivileged class may could gain unwarranted access to the resource.
Conversely, the assumption that two classes deriving from the same code base are themselves the same is error-prone. While this assumption is commonly observed to be true in desktop applications, it is typically not the case with J2EE servlet containers. The containers may can use different class loader instances to deploy and recall applications at runtime, without having to restart the JVM. In such situations, two objects whose classes come from the same code base may could appear to the JVM to be two different classes. Also note that the equals() method may might not return true when comparing objects originating from the same code base.
...
Comparing fully qualified class names is insufficient because distinct class loaders may can load differing classes with identical fully qualified names into a single JVM.
...
The call to loadClass() returns the class having with the specified name in the current name space (consisting of the class name and the defining class loader), and the comparison is correctly performed on the two class objects.
...
Comparing classes solely using their names may can allow a malicious class to bypass security checks and gain access to protected resources.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
OBJ06-J | high | unlikely | low | P9 | L2 |
Related Vulnerabilities
...
Bibliography
| Wiki Markup |
|---|
\[[Christudas 2005|AA. Bibliography#Christudas 05]\] Internals of Java Class Loading \[[JVMSpec 1999|AA. Bibliography#JVMSpec 99]\] [§2§2.8.1 Class Names|http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html] \[[Mcgraw 1998|AA. Bibliography#Mcgraw 98]\] Twelve rules for developing more secure Java code \[[MITRE 2009|AA. Bibliography#MITRE 09]\] [CWE ID 486|http://cwe.mitre.org/data/definitions/486.html] "Comparison of Classes by Name" \[[Wheeler 2003|AA. Bibliography#Wheeler 03]\] [Java|http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/java.html] Secure programming for Linux and Unix HOWTO |
...
OBJ05-J. Do not allow access to partially initialized objects 04. Object Orientation (OBJ) OBJ07-J. Preserve dependencies in subclasses when changing superclasses