Making defensive copies of mutable method parameters 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:
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
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:
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.
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 insertion into the database:
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:
This class was subsequently used by the Flashback exploit that infected 550,000 Macintosh computers in April 2012.1
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:
clone() method to copy untrusted arguments affords attackers the opportunity to execute arbitrary code.
|CERT.MET52.CIFC||Only "clone()" instances of "final" classes|
1 "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.