Page History

Java code that deals with input classes, for example Scanner and BufferedInputStream, often buffers its underlying InputStream.buffer the underlying input stream to facilitate fast, non-blocking I/O.

Since the InputStream class is abstract, a wrapper such as BufferedInputStream is required to provide a concrete implementation that overrides its methods. It is permissible It is possible to create multiple wrappers around on an InputStream that buffer the input from that InputStream. Such programs behave significantly differently . Programs that encourage multiple wrappers around the same stream, however, behave significantly different depending on whether the InputStream does or does not allow for read allows look-ahead. An adversary can exploit this difference in behavior by, for example, redirecting the InputStream, which could lead to exploitable behavior.Although the Java standard does not specifically mention this behavior, code compiled with javac and run with the java command exhibits this behavior on Java 1.5.0. System.in (from a file). This is also possible when a program uses the System.setIn() method to redirect System.in. That said, redirecting input from the console is a standard practice in *nix 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 buffered I/O is susceptible to misuse.

Do not create multiple wrappers that buffer their input on from an InputStream; . Instead, create and use only one wrapper, either by passing it as an argument to the methods that need it or centralizing its use in a single placedeclaring it as a class variable.

Noncompliant Code Example

This Despite just one declaration, this noncompliant code example creates multiple BufferedInputStreams BufferedInputStream wrappers on System.in, because each time getChar() is called, it makes conceives a new BufferedInputStream. Note that it does not matter that the old BufferedInputStream will have "expired" by the time the new one is created. Note that while Due to the inherent channeling and buffering mechanism, the data that is read from the underlying stream once cannot be replaced so that a second call can read the same data again. While this code uses a BufferedInputStream to illustrate that any buffered wrapper is unsafe, it this condition is also exploitable if a Scanner is used instead.

import java.io.BufferedInputStream;
import java.io.EOFException;

public final class InputLibrary {

  public static char getChar() throws EOFException {
    BufferedInputStream in = new BufferedInputStream(System.in); // wrapper
    int input = in.read();
    if (input == -1) {
    	throw new EOFException();
    }
    return (char)input; //okay because InputStream guarantees read() in range 0..255 if it is not -1
  }

  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.out.println("ERROR");
    }
  }
}

...

This program was compiled with the command javac InputLibrary.java on a system with Java 1.5.0. When run from the command line with java InputLibrary, the program will successfully take two characters as input and print them out. However, when run with java InputLibrary < input, where input is a file that contains the exact same input, the program prints "ERROR" because the second call to getChar() finds no characters to read upon encountering the end of the stream.

Compliant Solution

Create and use only a single BufferedInputStream on System.in. This compliant code example stores declares the BufferedInputStream as a class variable so that all methods can access it. However, if a program were to use this library in conjunction with other input from a user that also needs some buffered wrapper on System.in, the library would need to be modified so that all code uses the same buffered wrapper instead of creating separate additional ones.

import java.io.BufferedInputStream;
import java.io.EOFException;

public final class InputLibrary {

  private static BufferedInputStream in = new BufferedInputStream(System.in);

  public static char getChar() throws EOFException {
    int input = in.read();
    if (input == -1) {
    	throw new EOFException();
    }
    in.skip(1); // This statement now necessary to go to the next line
                // the Noncompliant code example deceptively worked without it
    return (char)input; //okay because InputStream guarantees read() will return an unsigned byte in the range 0..255 if it is not -1on success
  }

  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.out.println("ERROR");
    }
  }
}

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

Implementation Details

This program was compiled with the command javac InputLibrary.java on a system with Java 1.5.0. When run from the command line with java InputLibrary, the program will successfully take two characters as input and print them out. Also, when run with java InputLibrary < input, where input is a file that contains the exact same input, the program will successfully take two characters as input and print them out.

...