Page History

As the java.io.InputStream class is abstract, a wrapper such as BufferedInputStream is required to provide a concrete implementation that overrides its methods. Java input classes , for example such as Scanner and BufferedInputStream, often buffer the underlying input stream to facilitate fast, non-blocking nonblocking I/O . It is permissible to by buffering an underlying input stream. Programs can create multiple wrappers on an InputStream. Programs that encourage use multiple wrappers around the same a single input stream, however, can behave significantly different unpredictably depending on whether the InputStream allows wrappers allow look-ahead or not. An adversary attacker can exploit this difference in behavior by, for example, by redirecting System.in (from a file) . This is also possible when a program uses or by using the System.setIn() method to redirect System.in. That said, redirecting input from the console is a standard practice in UNIX based platforms but finds limited application in others such as Windows, where console programs are largely considered outmoded. In general, any input stream that supports non-blocking nonblocking buffered I/O is susceptible to this form of misuse.

Do not create multiple wrappers that buffer input from an InputStreamAn 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

Despite just one declaration, this This noncompliant code example creates multiple BufferedInputStream wrappers on System.in because each time , even though there is only one declaration of a BufferedInputStream. The getChar() is called, it conceives method creates a new BufferedInputStream. Because of the inherent channeling and buffering mechanism, the data each time it is called. Data that is read from the underlying stream once, and placed in the buffer during execution of one call cannot be replaced in the underlying stream so that a second call can read the same data again. While this code uses a BufferedInputStream to illustrate that 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 if when using a Scanner is used instead, for example.

public final class InputLibrary {
  public static char getChar() throws EOFException, IOException {
    BufferedInputStream in = new BufferedInputStream(System.in); // wrapperWrapper
    int input = in.read();
    if (input == -1) {
      throw new EOFException();
    }
    // Down casting is permitted because InputStream guarantees read() in range  
    // 0..255 if it is not -1
    return (char) input; 
  }

  public static void main(String[] args) {
    try {
      // Either redirect input from the console or use 
      // System.setIn(new FileInputStream("input.dat")); 
      System.out.print("Enter first initial: ");
      char first = getChar();
      System.out.println("Your first initial is " + first);
      System.out.print("Enter last initial: ");
      char last = getChar();
      System.out.println("Your last initial is " + last);
    } catch (EOFException e) {
      System.err.println("ERROR");
      // Forward to handler
    } catch (IOException e) {
      System.outerr.println("ERROR");
        // fowardForward to handler
    }
  }
}

Implementation Details

...

(POSIX)

When compiled under This program was compiled with the command javac InputLibrary.java on a system with Java 1.6.0 . When and run from the command line with java InputLibrary, the this program successfully takes two characters as input and prints them out. However, when run with java InputLibrary < input, where input is a file that contains the exact same a file redirected to standard input, the program throws an EOFException because the second call to getChar() finds no characters to read upon encountering the end of the stream.

It may appear that the mark() and 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 BufferedInputStream on System.in. This compliant solution declares ensures that all methods can access the BufferedInputStream by declaring it as a class variable so that all methods can access it. :

public final class InputLibrary {
  private static BufferedInputStream in =
      new BufferedInputStream(System.in);

  public static char getChar() throws EOFException, IOException {
    int input = in.read();
    if (input == -1) {
      throw new EOFException();
    }
    in.skip(1); // This statement is now necessary to goadvance to the next line.
                // The noncompliant code example deceptively worked
                // appeared to work without it (in some cases).
    return (char) input; 
  }

  public static void main(String[] args) {
    try {
      System.out.print("Enter first initial: ");
      char first = getChar();
      System.out.println("Your first initial is " + first);
      System.out.print("Enter last initial: ");
      char last = getChar();
      System.out.println("Your last initial is " + last);
    } catch (EOFException e) {
      System.err.println("ERROR");
      // Forward to handler
    } catch (IOException e) {
       System.outerr.println("ERROR");
       // Forward to handler
    }
  }
}

It may appear that the mark() and reset() methods of BufferedInputStream would replace the read bytes but this idea is deceptive, for, these methods provide look-ahead by operating on the internal buffers and not directly on the underlying stream.

Implementation Details

Implementation Details (POSIX)

When compiled under This program was compiled with the command javac InputLibrary.java on a system with Java 1.6.0 . When and run from the command line with java InputLibrary, the this program successfully takes two characters as input and prints them out. Also, Unlike the noncompliant code example, this program also produces correct output when run with java InputLibrary < input, where input is a file that contains the exact same input, the program successfully takes two characters as input and print them outa file redirected to standard input.

Compliant Solution

...

(Accessible Class Variable)

This compliant solution uses both System.in and the InputLibrary class, which creates a If a program intends to use the library InputLibrary in conjunction with other code that requires user input and consequently needs another buffered wrapper around System.in, its code must use the same buffered wrapper as the one used by the library, instead of creating and using an additional buffered wrapper. The library InputLibrary must return an instance of the buffered wrapper to support this functionality. 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 System.in.

public final class InputLibrary {
  private static BufferedInputStream in =
     new BufferedInputStream(System.in);

  // Other methods

  static BufferedInputStream getBufferedWrapper() {
    return in;
  }

  // ... Other methods
}


// Some code that requires user input from System.in
class AppCode {
  private static BufferedInputStream in;
  
  AppCode() {
    in =  InputLibrary.getBufferedWrapper();
  }

  // ... Other methods
}

Note that this scheme may not work very well in multi-threaded environments because by default, reading from a stream is not a thread-safe operation . Explicit by default; consequently, this compliant solution may be inappropriate in multithreaded environments. In such cases, explicit synchronization is required in such cases.

Risk Assessment

Creating multiple buffered wrappers around an InputStream can cause unexpected program behavior when the InputStream is re-directedredirected.

Automated Detection

TODO

Related Vulnerabilities

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

References

\[[API 06|AA. Java References#API 06]\] [method read|http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read()]
\[[API 06|AA. Java References#API 06]\] [class BufferedInputStream|http://java.sun.com/javase/6/docs/api/java/io/BufferedInputStream.html]

Sound automated detection of this vulnerability is not feasible in the general case. Heuristic approaches may be useful.

Bibliography

...

Image Added Image Added Image AddedFIO34-J. Do not create temporary files in shared directories      09. Input Output (FIO)      FIO37-J. Do not expose buffers created using the wrap() or duplicate() methods to untrusted code