Page History

Classes containing private, confidential, or otherwise sensitive data are best not copied. If a class is not meant to be copied, then failing to define copy mechanisms, such as a copy constructor, is insufficient to prevent copying.

Java's Object object cloning mechanism allows an attacker to manufacture new instances of a class , without executing its constructor. The new instances are made by copying the memory images of existing objects . Although rather than by executing the class's constructor. Often, this is sometimes an acceptable unacceptable way of creating new objects, it often is not. By misusing . An attacker can misuse the clone feature , an attacker can to manufacture multiple instances of a singleton class, create serious thread-safety issues by subclassing and cloning the subclass, bypass security checks within the constructor, and violate the invariants of critical data.

Classes that have security checks in their constructors must beware of finalization attacks, as explained in OBJ11-J. Be wary of letting constructors throw exceptions.

Classes that are not sensitive but maintain other invariants must be sensitive to the possibility of malicious subclasses accessing or manipulating their data and possibly invalidating their invariants (see OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code for more information).

Noncompliant Code Example

Consider the following noncompliant class definition. Unless someone knows the secret password, objects cannot be created. This is because the constructor for the class checks the input against the expected password before allowing object construction. It also performs a security check. The calling code uses a doPrivileged block to create an instance of SensitiveClass. Object creation beyond this block is prohibited by the security manager. However, since the SensitiveClass advertises a public clone() method, it is possible to circumvent this restriction. This clearly violates the principle of least privilege. Yet another blemish is the inconsistent security checkingThis noncompliant code example defines class SensitiveClass, which contains a character array used to hold a file name, along with a Boolean shared variable, initialized to false. This data is not meant to be copied; consequently, SensitiveClass lacks a copy constructor.

class SensitiveClass implements Cloneable {
  protected{
  private char[] filename;
  private Boolean shared = false;

  SensitiveClass(String passwdfilename) {
    this.filename = filename.toCharArray();
  }

  final  // perform security manager check
    System.out.println("SensitiveClass construction done!void replace() {
    if (!shared) {
      for(int i = 0; i < filename.length; i++) {
    	filename[i]= 'x' ;}
    }
  }

  final String get() {
    if (!shared) {
      shared = true;
      return String.valueOf(filename);
    } else {
      throw new IllegalStateException("Failed to get instance");
    }
  }

  protectedfinal void useprintFilename() {
    System.out.println("In method use()String.valueOf(filename));
  }
}

When a client requests a String instance by invoking the get() method, the shared flag is set. To maintain the array's consistency with the returned String object, operations that can modify the array are subsequently prohibited. As a result, the replace() method designed to replace all elements of the array with an x cannot execute normally when the flag is set. Java's cloning feature provides a way to circumvent this constraint even though SensitiveClass does not implement the Cloneable interface.

This class can be exploited by a malicious class, shown in the following noncompliant code example, that subclasses the nonfinal SensitiveClass and provides a public clone() method:

class MaliciousSubclass extends SensitiveClass implements Cloneable {
  protected MaliciousSubclass(String filename) {
    super(filename");
  }

  @Override public SensitiveClassMaliciousSubclass Cloneclone() {  // wellWell-behaved clone() method
    SensitiveClassMaliciousSubclass s = null;
    try {
      s = (SensitiveClassMaliciousSubclass)super.clone();	        
    } catch(Exception e) {
      System.out.println("not cloneable");
    }
    return s;
  }
}

class Foo {
public  protectedstatic void privilegedmain(String[] args) {
    final SensitiveClass[] scMaliciousSubclass ms1 = new SensitiveClass[2];

    AccessController.doPrivileged(new PrivilegedAction() {  MaliciousSubclass("file.txt");
    MaliciousSubclass ms2 public Object run= ms1.clone(); {
// Creates a copy
    String sc[0]s = new SensitiveClass("password"ms1.get();  // object creation with the passwordReturns filename
        sc[0].use(); System.out.println(s); //allowed
 Filename is "file.txt"
     return nullms2.replace();    
      }		
    });// Replaces all characters with 'x'
  
  //  sc[1] = sc[0].Clone(); // object creation without the passwordBoth ms1.get() and ms2.get() will subsequently return filename = 'xxxxxxxx'
    sc[1].usems1.printFilename();   // thisFilename should not be allowedbecomes 'xxxxxxxx'
  }

  public static void main(String[] args) {
    Foo f = new Foo();
    f.privileged();
  }
}

Compliant Solution

ms2.printFilename();   // Filename becomes 'xxxxxxxx'
  }
}

The malicious class creates an instance ms1 and produces a second instance ms2 by cloning the first. It then obtains a new filename by invoking the get() method on the first instance. At this point, the shared flag is set to true. Because the second instance ms2 does not have its shared flag set to true, it is possible to alter the first instance ms1 using the replace() method. This approach obviates any security efforts and severely violates the class's invariants.

Compliant Solution (Final Class)

The easiest way to prevent malicious subclasses is to declare SensitiveClass to be final.

final class SensitiveClass {
  // ...
}

Compliant Solution (Final clone())

Sensitive classes should neither implement the Cloneable interface nor provide a copy constructor. Sensitive classes that extend Sensitive classes should not implement the Cloneable interface. If the class extends from a superclass that implements Cloneable (and is therefore are cloneable ), it's as a result) must provide a clone() method should throw that throws a CloneNotSupportedException. This exception must be caught and handled by the client code. A sensitive class that does not implement Cloneable must also follow this advice because it inherits the clone() method from Object. The class can prevent subclasses from being made cloneable by defining a final clone() method that always fails.

class SensitiveClass {
  // ...
  public final SensitiveClass Cloneclone() 
                              throws CloneNotSupportedException {
    throw new CloneNotSupportedException();
  }

It is also required to declare SensitiveClass final so as to avoid malicious subclassing. This will stop an artful attacker from subclassing the sensitive class and creating several copies of the subclass, with the intention of introducing thread-safety issues.

Risk Assessment

}

This class fails to prevent malicious subclasses but does protect the data in SensitiveClass. Its methods are protected by being declared final. For more information on handling malicious subclasses, see OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code.

Risk Assessment

Failure to make sensitive classes noncopyable can permit violations of class invariants and provide malicious subclasses with the opportunity to exploit the code to create new instances of objects, even in the presence of the default security manager (in the absence of custom security checks).

References

\[[Mcgraw 98|AA. Java References#Mcgraw 98]\] 
\[[Wheeler 03|AA. Java References#Wheeler 03]\] 10.6. Java 
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 498|http://cwe.mitre.org/data/definitions/498.html] "Information Leak through Class Cloning", [CWE ID 491|http://cwe.mitre.org/data/definitions/491.html] "Public cloneable() Method Without Final (aka 'Object Hijack')"

Automated Detection

Related Guidelines

Bibliography

...

Image Added Image Added Image AddedMSC04-J. Be aware of JVM Monitoring and Managing      49. Miscellaneous (MSC)      MSC30-J. Generate truly random numbers