Page History

A mutable input has the characteristic that its value may vary; that is, multiple accesses may see differing values. This characteristic enables potential attacks that exploit race conditions. For example, a time-of-check, time-of-use (TOCTOU) inconsistency results vulnerability may result when a field contains a value that passes initial validation and security checks but mutates to a different value during actual changes before use.

Additionally, returning Returning references to an an object's internal mutable components provides an attacker with the opportunity to corrupt the state of the object. Accessor Consequently, accessor methods must consequently return defensive copies of internal mutable objects ; (see rule OBJ05-J. Defensively copy Do not return references to private mutable class members before returning their references for additional more information).

Noncompliant Code Example

This noncompliant code example contains a TOCTOU inconsistency vulnerability. Because cookie is a mutable input, an attacker can cause the cookie it to expire between the initial check (the hasExpired() call) and the actual use (the doLogic() call).

public final class MutableDemo {
  // java.net.HttpCookie is mutable
  public void useMutableInput(HttpCookie cookie) {
    if (cookie == null) {
       throw new NullPointerException();
    }

    // Check whether cookie has expired
    if (cookie.hasExpired()) {
      // Cookie is no longer valid,; handle condition by throwing an exception
    }

    // Cookie may have expired since time of check 
    doLogic(cookie);
  }
}

...

This compliant solution avoids the TOCTOU vulnerability by copying the mutable input and performing all operations on the copy. Consequently, an attacker's changes to the mutable input cannot affect the copy. Acceptable techniques include using a copy constructor or implementing the java.lang.Cloneable interface and declaring a public public clone() method (for classes not declared as final). In cases like such as HttpCookie where the mutable class is declared final — that final—that is, it cannot provide an accessible copy method — perform method—perform a manual copy of the object state within the caller . See rule (see OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code safely for more information). Note that any input validation must be performed on the copy and not rather than on the original object.

public final class MutableDemo {
  // java.net.HttpCookie is mutable
  public void useMutableInput(HttpCookie cookie) {
    if (cookie == null) {
      throw new NullPointerException();
    }

    // Create copy
    cookie = (HttpCookie)cookie.clone();

    // Check whether cookie has expired
    if (cookie.hasExpired()) {
      // Cookie is no longer valid,; handle condition by throwing an exception
    }

    doLogic(cookie);
  }
}

Compliant Solution

You must make defensive copies of all mutable inputs to comply with this rule. Some copy constructors and clone() methods perform a shallow copy of the original instance. For example, invocation of clone() on an array results in creation of an array instance whose elements have the same values as the original instance. This shallow copy is sufficient for arrays of primitive types , but fails to protect against TOCTOU vulnerabilities when the elements are references to mutable objects. Use a deep copy that performs element duplication when the input consists of mutable components, such as an array of cookies. Such cases require a deep copy that also duplicates the reference objects.

This compliant solution demonstrates correct use both of a shallow copy (for the array of int) and also of a deep copy (for the array of cookies).:

  public void deepCopy(int[] ints, HttpCookie[] cookies) {
    if (ints == null || cookies == null) {
      throw new NullPointerException();
    }

    // Shallow copy
    int[] intsCopy = ints.clone();

    // Deep copy
    HttpCookie[] cookiesCopy = new HttpCookie[cookies.length];
    for (int i = 0; i < cookies.length; i++) {
      // Manually create copy of each element in array
      cookiesCopy[i] = (HttpCookie)cookies[i].clone();
    }
 
    doLogic(intsCopy, cookiesCopy);
}

...

When the class of a mutable input is non-final, nonfinal or is an interface, an attacker can write a subclass that maliciously overrides the parent class's clone() method. The attacker's clone() method could then can subsequently subvert defensive copying. This noncompliant code example demonstrates the this weakness.:

// java.util.Collection is an interface
public void copyInterfaceInput(Collection<String> collection) {
  doLogic(collection.clone());
}

Compliant Solution

This compliant solution protects against potential malicious overriding by creating a new instance of the non-final nonfinal mutable input, using the expected class rather than the class of the potentially malicious provided objectargument. The newly created instance can be forwarded to any code capable of modifying it.

public void copyInterfaceInput(Collection<String> collection) {
  // Convert input to trusted implementation
  collection = new ArrayList(collection);
  doLogic(collection);
}

Some objects appear to be immutable because they have no mutator methods. For example, the java.lang.CharacterSequenceCharSequence interface describes an immutable sequence of characters. Note, however, that a variable of type CharacterSequence CharSequence is a reference to an underlying object of some other class that implements the CharacterSequence CharSequence interface; that other class may be mutable. When the underlying object changes, the CharacterSequence CharSequence changes. Essentially, the java.lang.CharacterSequenceCharSequence interface omits methods that would permit object mutation through that interface, but lacks any guarantee of true immutability. Such objects must still be defensively copied before use. For the case of the java.lang.CharacterSequenceCharSequence interface, one permissible approach is to obtain an immutable copy of the characters by using the toString() method. Mutable fields should not be stored in static variables. When there is no other alternative, create defensive copies of the fields to avoid exposing them to untrusted code.

Risk Assessment

Failing to create a copy of a mutable input may enable an attacker to exploit a TOCTOU vulnerability and at other times, result in a TOCTOU vulnerability or expose internal mutable components to untrusted code.

Automated Detection

...

Tool	Version	Checker	Description
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	CERT.OBJ06.CPCL CERT.OBJ06..MPT CERT.OBJ06.SMO CERT.OBJ06.MUCOP	Enforce returning a defensive copy in 'clone()' methods Do not pass user-given mutable objects directly to certain types Do not store user-given mutable objects directly into variables Provide mutable classes with copy functionality
SonarQube	Include Page SonarQube_V SonarQube_V	S2384	Mutable members should not be stored or returned directly Implemented for Arrays, Collections and Dates.

Related Vulnerabilities

CVE-2012-0507 describes an exploit that managed to bypass Java's applet security sandbox and run malicious code on a remote user's machine. The exploit created a data structure that is normally impossible to create in Java but was built using deserialization, and the deserialization process did not perform defensive copies of the deserialized data. See the code examples in SER07-J. Do not use the default serialized form for classes with implementation-defined invariants for more information.

Related Guidelines

Bibliography

...

Image Added Image Added

TODO

Related Vulnerabilities

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

Bibliography

OBJ05-J. Defensively copy private mutable class members before returning their references      04. Object Orientation (OBJ)      Image Modified