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 SEC12-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 for additional information.

Noncompliant Code Example (CVE-2008-5353: Zoneinfo)

\[[CVE|AA. Bibliography#CVE]\] [CVE-2008-5353 |http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5353] describes a Java vulnerability, discovered in August 2008 by Sami Koivu. Julien Tinnes subsequently wrote an exploit that allowed arbitrary code execution on multiple platforms that ran vulnerable versions of Java. The problem resulted from deserializing untrusted input from within a privileged context. The vulnerability involves the ({{sun.util.Calendar.Zoneinfo}}) object, which being a serializable class, is deserialized by the {{readObject()}} method of the {{ObjectInputStream}} class.

...

try {
  ZoneInfo zi = (ZoneInfo) AccessController.doPrivileged(
    new PrivilegedExceptionAction() {
      public Object run() throws Exception {
        return input.readObject();
      }
  });
  if (zi != null) {
    zone = zi;
  }
} catch (Exception e) {
}

Compliant Solution (CVE-2008-5353: Zoneinfo)

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.

private static class CalendarAccessControlContext {
  private static final AccessControlContext INSTANCE;
    static {
      RuntimePermission perm = new RuntimePermission("accessClassInPackage.sun.util.calendar");
      PermissionCollection perms = perm.newPermissionCollection();
      perms.add(perm);
      INSTANCE = new AccessControlContext(new ProtectionDomain[] {
        new ProtectionDomain(null, perms)
      });
    }
  }

// ...
try {
  zi = AccessController.doPrivileged(
       new PrivilegedExceptionAction<ZoneInfo>() {
         public ZoneInfo run() throws Exception {
           return (ZoneInfo) input.readObject();
         }
       }, CalendarAccessControlContext.INSTANCE);
} catch (PrivilegedActionException pae) { /* ... */ }
if (zi != null) {
  zone = zi;
}

Risk Assessment

Deserializing objects from an unrestricted privileged context can result in arbitrary code execution.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Bibliography

...