Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Major rewording to clarify the underlying problem.

The buffer classes (such as defined in the java.nio package (e.g. IntBuffer, CharBuffer and ByteBuffer) defined in the java.nio package define define a variety of wrap() methods, varying in parameters. The . Although these wrap() methods create a new Buffer object, however, the elements continue to persist in the backing array from which the buffer was created. If the buffer is altered by untrusted code, the backing array is maliciously modifiedthe new Burrer 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() method allows the creation of copies of the buffer but a caller may indirectly alter creates additional buffers 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 backing buffer.

...

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

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

...

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

...

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

Code Block
bgColor#ccccff
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;
  }
}

...

This noncompliant code example uses the duplicate() method to create and return a copy of the CharBuffer. The returned buffer allows the caller to indirectly 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.

Code Block
bgColor#FFCCCC
final class Dup {
  CharBuffer cb;
 
  public Dup() {
    cb = CharBuffer.allocate(10);
    // Initialize
  }

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

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

Noncompliant Code Example

Creating This noncompliant code example attempts to repair the above vulnerability by allocating a new CharBuffer, allocating it using allocate() and duplicating and storing another CharBuffer into it, does not prevent the contents of the duplicated buffer from being modifiedthe 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.

Code Block
bgColor#FFCCCC
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;
  }
}

...

Guideline

Severity

Likelihood

Remediation Cost

Priority

Level

FIO01-J

medium

likely

low

P18

L1

Automated Detection

TODOSound 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.

...