...
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. Thus, 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 non-serializable most derived superclass's constructor (all the way upto Object's constructorfor instance, if class A derives from class B which in turn derives from class C, class C's constructor will be executed when A is deserialized. If B implements Serializable then A may not implement it) and proceeds to deserialize the necessary call Object's constructor. Subsequently, the fields of the subclass are deserialized. At this point, there is no subclass code on the stack and the most derived superclass's constructor is executed with no restrictions since doPrivileged() takes the intersection of the privileges of all the caller codes present on the stack. Since allows the immediate caller to exert its full privileges. Since the immediate caller java.util.Calendar is trusted, it exhibits full system privileges when used with a doPrivileged() block.
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 filesystem. Moreover, any legitimate security checks in the constructor are meaningless as the code is granted all privileges.
...