FIO01-J. Do not expose buffers created using the wrap() or duplicate() methods to untrusted code

The buffer classes defined in the java.nio package (e.g. IntBuffer, CharBuffer and ByteBuffer) define a variety of wrap() methods. Although these wrap() methods create a new Buffer object, the new Buffer is backed by the array for which it is created. According to the JavaDoc for these methods:

The new buffer will be backed by the given character array; that is, modifications to the buffer will cause the array to be modified and vice versa.

Consequently, exposing the buffer to untrusted code exposes the backing array to malicious modification. Likewise, the duplicate() methods create additional buffers that are backed by the original buffer's backing array; exposing such additional buffers to untrusted code affords the same opportunity for malicious modification of the contents of the original buffer's backing store.

Noncompliant Code Example

This noncompliant code example declares a char array, wraps it with a Buffer and exposes that Buffer to untrusted code via the getBufferCopy() method. The return value of this method is of type CharBuffer.

final class Wrap {
  private char[] dataArray;
  
  public Wrap () {
    dataArray = new char[10];
    // Initialize
  }
	
  public CharBuffer getBufferCopy() {
    return CharBuffer.wrap(dataArray);	
  }
}

Compliant Solution

This compliant solution returns a read-only view of the char array, in the form of a read-only CharBuffer. The standard library implementation of CharBuffer guarantees that attempts to modify the elements of a read-only CharBuffer will result in a java.nio.ReadOnlyBufferException.

final class Wrap {
  private char[] dataArray;

  public Wrap () {
    dataArray = new char[10];
    // Initialize
  }
	
  public CharBuffer getBufferCopy() {
    CharBuffer cb = CharBuffer.allocate(10);
    return cb.asReadOnlyBuffer();
  }
}

Compliant Solution

This compliant solution allocates a new CharBuffer and explicitly copies the contents of the char array into it, before returning the copy. Consequently, malicious callers can modify the copy of the array, but cannot modify the original.

final class Wrap {
  private char[] dataArray;
  
  public Wrap () {
    dataArray = new char[10];
    // Initialize
  }
	
  public CharBuffer getBufferCopy() {
    CharBuffer cb = CharBuffer.allocate(10);
    cb.put(dataArray);
    return cb;
  }
}

Noncompliant Code Example

This noncompliant code example uses the duplicate() method to create and return a copy of the CharBuffer. As stated in the contract for the duplicate() method, the returned buffer is backed by the same array as is the original buffer. Consequently, a caller can modify the elements of the backing array; these modifications also affect the original buffer.

final class Dup {
  CharBuffer cb;
 
  public Dup() {
    cb = CharBuffer.allocate(10);
    // Initialize
  }

  public CharBuffer getBufferCopy() {	
    return cb.duplicate();
  }
}

When the CharBuffer created by the duplicate() method is based on a CharBuffer originally obtained by using the wrap() method, modifying the CharBuffer returned by the duplicate() method also modifies the contents of the backing char array; this property can be useful to a malicious attacker.

Noncompliant Code Example

This noncompliant code example attempts to repair the above vulnerability by allocating a new CharBuffer, and duplicating the CharBuffer into the newly allocated CharBuffer. This approach fails to protect the contents of the duplicated buffer, because the duplicate() method only duplicates the wrapping buffer fields and produces a buffer with the same backing store as the original buffer.l Consequently, malicious modifications to the duplicated buffer also affect the backing store of the original buffer.

final class Dup {
  CharBuffer cb;
 
  public Dup() {
    cb = CharBuffer.allocate(10);
    // Initialize
  }

  public CharBuffer getBufferCopy() {	
    CharBuffer copy = CharBuffer.allocate(10);
    copy = cb.duplicate();
    return copy;
  }
}

Compliant Solution

This compliant solution exposes a read-only view of the CharBuffer to untrusted code.

final class Dup {
  CharBuffer cb;
 
  public Dup() {
    cb = CharBuffer.allocate(10);
    // Initialize
  }

  public CharBuffer getBufferCopy() {	
    return cb.asReadOnlyBuffer();
  }
}

Risk Assessment

Returning buffers created using the wrap() or duplicate() methods may allow an untrusted caller to alter the contents of the original data.

Automated Detection

Sound automated detection of this vulnerability is not feasible. Heuristic approaches may be useful.

Related Vulnerabilities

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

Bibliography

[[API 2006]] class CharBuffer
[[Hitchens 2002]] 2.3 Duplicating Buffers

FIO00-J. Defensively copy mutable inputs and mutable internal components      09. Input Output (FIO)      FIO02-J. Keep track of bytes read and account for character encoding while reading data