...
Consider the default security model of an applet that does not allow access to sun.util.calendar.ZoneInfo since all classes within the "sun" package are treated as untrusted. ThusAs a result, prior to JDK 1.6 u11, the acceptable method for an unsigned applet to deserialize a Zoneinfo object was to execute the call from a privileged context, such as a doPrivileged() block. This constitutes a vulnerability since there is no surefire method of knowing whether the serialized stream contains a Zoneinfo object and not a malicious serializable class. The vulnerable code casts the malicious object to the ZoneInfo type which typically causes a ClassCastException. This exception however, is of little consequence as it is possible to store a reference to the newly created object in some static context so that the garbage collector does not act upon it.
A non-serializable or serializable class can be extended and its subclass can be made serializable or becomes so automatically. During deserialization of the subclass, the JVM calls the no-argument constructor of the most derived superclass that does not implement java.io.Serializable either directly or indirectly. When an object is deserialised the no-argument constructor of the most derived superclass that does not directly or indirectly implement java.io.Serializable is executed. In the code snippet that immediately follows, class A's no-argument constructor is called when C is deserialized since A does not implement Serializable. Subsequently, Object's constructor is invoked. This procedure cannot be carried out programmatically, therefore consequently the JVM generates the equivalent bytecode at runtime. Typically, when the superclass's constructor is called by a subclass, the subclass remains on the stack. However, in deserialization this does not happen. Only the unvalidated bytecode is present. This allows any security checks within the superclass's constructor to be bypassed.
...
For exploiting this condition, often, a custom class loader is desirable. Instantiating a class loader object requires special permissions that are made available by the security policy that is enforced by the SecurityManager. An unsigned applet cannot carry out this step by default. If an unsigned applet can execute a custom class loader's constructor, it can effectively bypass all the security checks (since it has the requisite privileges as a direct consequence of the vulnerability). A custom class loader can be designed to extend the System Class Loader, undermine security and carry out forbidden functions such as reading or deleting files on the userâs filesystemfile system. Moreover, any legitimate security checks in the constructor are meaningless as the code is granted all privileges.
...
This vulnerability was fixed in JDK v1.6 u11 by defining a new AccessControlContext INSTANCE, with a new ProtectionDomain. The ProtectionDomain encapsulated a RuntimePermission called accessClassInPackage.sun.util.calendar. ThereforeConsequently, the code was granted just about enough permissions to access the sun.util.calendar class. This whitelisting approach guaranteed that a security exception would be thrown in all other cases of invalid access.
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
SER37- J | high | likely | medium | P12 P18 | L2 L1 |
Automated Detection
TODO
Related Vulnerabilities
...