Java input classes such as
BufferedInputStream facilitate fast, nonblocking I/O by buffering an underlying input stream. Programs can create multiple wrappers on an
InputStream. Programs that use multiple wrappers around a single input stream, however, can behave unpredictably depending on whether the wrappers allow look-ahead. An attacker can exploit this difference in behavior, for example, by redirecting
System.in (from a file) or by using the
System.setIn() method to redirect
System.in. In general, any input stream that supports nonblocking buffered I/O is susceptible to this form of misuse.
An input stream must not have more than one buffered wrapper. Instead, create and use only one wrapper per input stream, either by passing it as an argument to the methods that need it or by declaring it as a class variable.
Likewise, an output stream must not have more than one buffered wrapper because multiple wrappers can cause multiple output strings to be output in an unexpected order. For example, the
javax.servlet.ServletResponse allows for the creation of a
PrintWriter or an
OutputStream to hold the response generated by a web servlet. But only one or the other should be used, not both.
Noncompliant Code Example
This noncompliant code example creates multiple
BufferedInputStream wrappers on
System.in, even though there is only one declaration of a
getChar() method creates a new
BufferedInputStream each time it is called. Data that is read from the underlying stream and placed in the buffer during execution of one call cannot be replaced in the underlying stream so that a second call has access to it. Consequently, data that remains in the buffer at the end of a particular execution of
getChar() is lost. Although this noncompliant code example uses a
BufferedInputStream, any buffered wrapper is unsafe; this condition is also exploitable when using a
Scanner, for example.
Implementation Details (POSIX)
When compiled under Java 1.6.0 and run from the command line, this program successfully takes two characters as input and prints them out. However, when run with a file redirected to standard input, the program throws
EOFException because the second call to
getChar() finds no characters to read upon encountering the end of the stream.
It may appear that the
reset() methods of
BufferedInputStream could be used to replace the read bytes. However, these methods provide look-ahead by operating on the internal buffers of the
BufferedInputStream rather than by operating directly on the underlying stream. Because the example code creates a new
BufferedInputStream on each call to
getchar(), the internal buffers of the previous
BufferedInputStream are lost.
Compliant Solution (Class Variable)
Create and use only a single
System.in. This compliant solution ensures that all methods can access the
BufferedInputStream by declaring it as a class variable:
Implementation Details (POSIX)
When compiled under Java 1.6.0 and run from the command line, this program successfully takes two characters as input and prints them out. Unlike the noncompliant code example, this program also produces correct output when run with a file redirected to standard input.
Compliant Solution (Accessible Class Variable)
This compliant solution uses both
System.in and the
InputLibrary class, which creates a buffered wrapper around
System.in. Because the
InputLibrary class and the remainder of the program must share a single buffered wrapper, the
InputLibrary class must export a reference to that wrapper. Code outside the
InputLibrary class must use the exported wrapper rather than create and use its own additional buffered wrapper around
Note that reading from a stream is not a thread-safe operation by default; consequently, this compliant solution may be inappropriate in multithreaded environments. In such cases, explicit synchronization is required.
Creating multiple buffered wrappers around an
InputStream can cause unexpected program behavior when the
InputStream is redirected.
Sound automated detection of this vulnerability is not feasible in the general case. Heuristic approaches may be useful.
|CERT.FIO06.MULBUF||Do not create multiple buffered wrappers on a single byte or character stream|
|[API 2014]||Class |
|[Fortify 2014]||Multiple Stream Commits|