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