Page History

Unrestricted deserializing from a privileged context allows an attacker to supply crafted input which, upon deserialization, can yield objects that the attacker lacks permissions to construct. One example of this is the construction of a sensitive object, such as a custom class loader. Consequently, avoid deserializing from a privileged context. When deserializing requires privileges, programs must strip all permissions other than the minimum set required for the intended usage. See rules void SEC12the rule SEC02-J. Do not grant untrusted code access to classes in inaccessible packages and void SEC13-J. Do not allow unauthorized construction of classes in inaccessible packages Remove superfluous code from privileged blocks for additional information.

...

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. Consequently, the code was granted the minimal set of permissions required 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. Refer to rule void SEC12-J. Do not grant untrusted code access to classes in inaccessible packages for more details on allowing or disallowing access to packages. Finally, the two-argument form of doPrivileged() allows stripping all permissions other than the ones specified in the ProtectionDomain.

...

...