Page History

Problems may arise if Making defensive copies of untrusted mutable method parameters are made and security decisions are based on these copies. An attacker can sufficiently bypass security checks under such circumstances.

Noncompliant Code Example

mitigates 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 might be 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 OBJ57-J. Do not rely on methods that can be overridden by untrusted code.

Noncompliant Code Example

This noncompliant code example defines a validateValue() method that validates a time value:This noncompliant code example accepts an untrusted parameter and creates a copy using the clone() method. This is not a good idea because a copy of the attacker's class is created instead of the system class. Any input validation routines may not work as expected when the attacker overrides the getTime() method so that it passes validation when called for the first time, but mutates when it is used a second time. Here, the validateValue() method is required to protect insertion of time data prior to some known time but fails to achieve this purpose.

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

private void storeDateinDBstoreDateInDB(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 attacker can override the getTime() method as shown below.

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 bypass validation but still confound 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 actually stored in the database will be incorrect.

Compliant Solution

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

private void storeDateinDBstoreDateInDB(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());
    // ...
  }
}	

Risk Assessment

Using the clone() method to copy untrusted parameters can lead to the execution of arbitrary code.

Automated Detection

TODO

Related Vulnerabilities

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

References

\[[Sterbenz 06|AA. Java References#Sterbenz 06]\] 

Noncompliant Code Example (CVE-2012-0507)

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

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

This class was subsequently used by the Flashback exploit that infected 550,000 Macintosh computers in April 2012.¹

Compliant Solution (CVE-2012-0507)

In Java 1.7.0 update 3, the constructor was modified to use the Arrays.copyOf() method instead of the clone() method, 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.

Automated Detection

Bibliography

¹ "Exploiting Java Vulnerability CVE-2012-0507 Using Metasploit" is shared by user BreakTheSec on Slideshare.net (July 14, 2012). www.slideshare.net/BreakTheSec/exploiting-java-vulnerability.

...

Image Added Image Added Image AddedMET37-J. Do not call overridable methods from a privileged block      11. Methods (MET)      MET35-J. Ensure that the clone method calls super.clone