Versions Compared

Key

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

A Serializable class can overload the Serializable.readObject() method, which is called when an object of that class is being deserialized.  Both this method and the method the readResolve() must treat the serialized data as potentially malicious and must  method should refrain from performing potentially dangerous operations, unless the programmer has expressly indicated for the particular deserialization at hand, that the class should be permitted to perform potentially dangerous operations.  

 A class that performs dangerous operations in the constructor must not be Serializable. This is because SER07-J. Do not use the default serialized form for classes with implementation-defined invariants would require that its readObject() method perform the same dangerous operation as the constructor. As an alternative, such a class  could be Serializable if readObject() always throws an exception.

This guideline is related to rule SER12-J. Prevent deserialization of untrusted dataThis rule complements rule SER12-J. Prevent deserialization of untrusted classes.  Whereas SER12-J requires the programmer to ensure the absence of classes that might perform dangerous operations when deserialized by validating data before deserializing it, SER13-J requires that all serializable classes refrain, by default, from performing dangerous operations during deserialization.  SER12-J and SER13-J both guard against the same class of deserialization vulnerabilities.  Theoretically, a given system is secure against this class of vulnerabilities if either (1) all deployed code on that system follows SER12-J or (2) all deployed code on that system follows SER13-J.  However, because much existing code violates these rules, the CERT Coding Standard takes the "belt and suspenders" approach and requires compliant code to follow both rules.

Non-Compliant Code Example

The class OpenedFile in In the following non-compliant code example opens , the class OpenedFile opens a file during deserialization.  Operating systems typically impose a limit on the number of open file handles per process; . Usually, this limit typically is not large (e.g., 1024).  Consequently, deserializing a list of OpenedFile objects can consume all file handles available to the process and consequently cause the program to malfunction if it attempts to open another file before the deserialized OpenedFile objects get garbage-collected.

Code Block
bgColor#FFcccc
languagejava
import java.io.*;

class OpenedFile implements Serializable {
  public String filename;
  public BufferedReader reader;

  public OpenedFile(String _filename) throws FileNotFoundException {
    this.filename = _filename;
    init();
  }

  private void init() throws FileNotFoundException {
    reader = new BufferedReader(new FileReader(filename));
  }
    
  private void writeObject(ObjectOutputStream out) throws IOException {
    out.writeUTF(filename);
  }

  private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
    filename = in.readUTF();
    init();
  }
} 

Compliant Solution

In this compliant solution, the readObject() method throws an exception unless the potentially dangerous class is whitelistedpotentially dangerous operations are moved outside of deserialization, and users of the class are required to make a separate call to init() after deserializing.

Code Block
bgColor#ccccff
languagejava
import java.io.*;
 
interface Whitelist {
  public boolean contains(String className);
}
 
class WhitelistedObjectInputStream extends ObjectInputStream {
  Whitelist whitelist;
 
  public WhitelistedObjectInputStream(InputStream inputStreamclass OpenedFile implements Serializable {
  String filename;
  BufferedReader reader;
  boolean isInitialized;

  public OpenedFile(String filename) {
    this.filename = filename;
    isInitialized = false;
 }

  public void init() throws FileNotFoundException {
    reader = new BufferedReader(new FileReader(filename));
    isInitialized = true;
 }
     
  private void writeObject(ObjectOutputStream out) throws IOException {
    superout.writeUTF(inputStreamfilename);
  }
 
  publicprivate void setWhitelistreadObject(WhitelistObjectInputStream wlin) throws IOException, ClassNotFoundException {
    whitelistfilename = wlin.readUTF();
    isInitialized = false;
 }
}

Compliant Solution

In this compliant solution, we assume that OpenedFile must be Serializable because it inherits from a serializable superclass. Because OpenedFile must perform dangerous operations in the constructor, it intentionally forbids deserialization by throwing an exception in readObject().

 

Code Block
bgColor#ccccff
languagejava
import java.io.*;
 
class OpenedFileUnchangeable implements Serializable {
  // ...
}
class OpenedFile extends Unchangeable  public{ // Serializable, unfortunately
  String filename;
  public BufferedReader reader;
  boolean isInitialized;

  public OpenedFile(String _filename) throws FileNotFoundException {
    this.filename = _filename;
    init()isInitialized = false;
   }

  public private void init() throws FileNotFoundException {
    reader = new BufferedReader(new FileReader(filename));
    isInitialized = true;
 }
     
  private void writeObject(ObjectOutputStream out) throws IOException {
    out.writeUTF(filename);
  }

  private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
    booleanthrow isWhitelistednew = ((in instanceof WhitelistedObjectInputStream) &&
      ((WhitelistedObjectInputStream) in).whitelist.contains(this.NotSerializableException(OpenedFile.getClass().getName()));
    if (!isWhitelisted) {
      throw new SecurityException("Attempted to deserialize unexpected class.");
    }
    filename = in.readUTF();
    init();
  }
}

...

 }
}

Related Vulnerabilities

CERT Vulnerability #576313 describes a family of exploitable vulnerabilities that arise from violating this rule.

Risk Assessment

The severity of violations of this rule depend on the nature of the potentially dangerous operations performed.  If only mildly dangerous operations are performed, the risk might be limited to denial-of-service (DoS) attacks.  At the other extreme, remote code execution is possible if attacker-supplied input is supplied to methods such as Runtime.exec (either directly or via reflection).

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SER13SEC58-J

High

LikelyHighP9L2

Automated Detection

Tool
Version
Checker
Description

ysoserial

  Useful for developing exploits that detect violation of this rule

Related Guidelines

MITRE CWE

CWE-502, Deserialization of Untrusted Data

Bibliography

Image Modified Image Modified Image Modified