Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Unrestricted deserializing from a privileged context allows an attacker to supply crafted input which, upon deserialization, can yield objects that the attacker does not have permissions to construct. Construction of a custom class loader is one example (See SEC07-J. Do not grant untrusted code access to classes existing in forbidden packages).

Noncompliant Code Example

In Aug August 2008 a vulnerability in the JDK was discovered by Sami Koivu. Julien Tinnes wrote an exploit that allowed arbitrary code execution on multiple platforms that ran vulnerable versions of Java. The problem surfaced primarily because of resulted from deserializing untrusted input from within a privileged context. The vulnerability involves the ZoneInfo object (sun.util.Calendar.Zoneinfo), which being a serializable class, is by design deserialized by the readObject() method of the ObjectInputStream class.

Consider the default security model of an applet that does not allow access to sun.util.calendar.ZoneInfo because all classes within the "sun" package are treated as untrusted. As 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 because there is no surefire guaranteed 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.

...

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 just about enough permissions 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 SEC07-J. Do not grant untrusted code access to classes existing in forbidden packages for more details on allowing or disallowing access to packages.

...