10. Do not use the clone method to copy untrusted method parameters

Making defensive copies of mutable method parameters mitigate against a variety of security vulnerabilities; see OBJ06-J. Defensively copy mutable inputs and mutable internal components for additional information. However, inappropriate use of the clone() method can allow an attacker to exploit vulnerabilities by providing arguments that appear normal but subsequently return unexpected values. Such objects may consequently bypass validation and security checks. When such a class is passed as an argument to a method, treat the argument as untrusted and do not use the clone() method provided by the class. Also, do not use the clone() method of nonfinal classes to make defensive copies.

This guideline is a specific instance of OBJ58-JG. Do not rely on overridden methods provided by untrusted code.

Noncompliant Code Example

This noncompliant code example defines a validateValue() method that validates a time value:

private Boolean validateValue(long time) {
  // Perform validation
  return true; // If the time is valid	
}

private void storeDateInDB(java.util.Date date) throws SQLException {
  final java.util.Date copy = (java.util.Date)date.clone();
  if (validateValue(copy.getTime())) {
    Connection con = DriverManager.getConnection("jdbc:microsoft:sqlserver://<HOST>:1433","<UID>","<PWD>");
    PreparedStatement pstmt = con.prepareStatement("UPDATE ACCESSDB SET TIME = ?");
    pstmt.setLong(1, copy.getTime());
    // ...
  } 
}	

The storeDateInDB() method accepts an untrusted date argument and attempts to make a defensive copy using its clone() method. This allows an attacker to take control of the program by creating a malicious date class that extends Date. If the attacker's code runs with the same privileges as storeDateInDB(), the attacker merely embeds malicious code inside their clone() method:

class MaliciousDate extends java.util.Date {
  @Override
  public MaliciousDate clone() {
    // malicious code goes here
  }
}

If, however, the attacker can only provide a malicious date with lessened privileges, the attacker can still produce a malicious date that bypasses validation, but still confounds the remainder of the program. Consider this example:

public class MaliciousDate extends java.util.Date {
  private static int count = 0;
 
  @Override
  public long getTime() {
    java.util.Date d = new java.util.Date();
    return (count++ == 1) ? d.getTime() : d.getTime() - 1000;
  }
}

This malicious date will appear to be a benign date class the first time that getTime() is invoked. This allows it to bypass validation in the storeDateInDB() method. However, the time that is actaully stored in the database will be incorrect.

Compliant Solution

This compliant solution avoids using the clone() method. Instead, it creates a new java.util.Date object that is subsequently used for access control checks and for insertion into the database:

private void storeDateInDB(java.util.Date date) throws SQLException {
  final java.util.Date copy = new java.util.Date(date.getTime());
  if (validateValue(copy.getTime())) {
    Connection con = DriverManager.getConnection("jdbc:microsoft:sqlserver://<HOST>:1433","<UID>","<PWD>");
    PreparedStatement pstmt = con.prepareStatement("UPDATE ACCESSDB SET TIME = ?");
    pstmt.setLong(1, copy.getTime());
    // ...
  }
}	

Noncompliant Code Example (CVE-2012-0507)

This noncompliant code example shows a constructor of the class AtomicReferenceArray as of Java 1.7.0 update 2:

public AtomicReferenceArray(E[] array) {
    // Visibility guaranteed by final field guarantees
    this.array = array.clone();
}

This code was subsequently invoked by an exploit called Flashback that infected 600,000 Macintosh computers in April 2012.

Compliant Solution (CVE-2012-0507)

In Java 1.7.0 update 3, this code was modified as follows:

public AtomicReferenceArray(E[] array) {
    // Visibility guaranteed by final field guarantees
    this.array = Arrays.copyOf(array, array.length, Object[].class);
}

Applicability

Using the clone() method to copy untrusted arguments affords attackers the opportunity to execute arbitrary code.

Bibliography