Page History

Java programs can get input from a user by creating a Scanner on System.in. A program can even get input from a user by creating multiple Scanners on System.in and using each. While this program will work properly when System.in refers to the console, it will crash when System.in has been re-directed, which could lead to exploitable behavior.

Although the Java standard does not specifically mention this behavior, code running on Eclipse with Java 1.6 exhibits this behavior.

input classes such as Scanner and 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 streamDo not create multiple Scanners on System.in; create and use only one, either by passing it as an argument to the methods that need it or centralizing its use in a single placeby 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 Scanners BufferedInputStream wrappers on System.in. Although it will work when System.in refers to a console, it crashes when System.in has been redirected, even though there is only one declaration of a BufferedInputStream. The 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.

import java.util.Scanner;

public final class InputLibrary {

  public static intchar getIntgetChar() throws EOFException, IOException {
    ScannerBufferedInputStream in = new ScannerBufferedInputStream(System.in); // Wrapper
    int returninput = in.nextIntread();
  }

  publicif static(input double getDouble(== -1) {
    Scanner in =throw new ScannerEOFException(System.in);
    return in.nextDouble()}
    // 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 intinitial: ");
      intchar first i=getInt(= getChar();
      System.out.println("Your first initial is " + first);
      System.out.print("Enter last doubleinitial: ");
      doublechar last d=getDouble();
  }
}

...

= getChar();
      System.out.println("Your last initial is " + last);
    } catch (EOFException e) {
      System.err.println("ERROR");
      // Forward to handler
    } catch (IOException e) {
      System.err.println("ERROR");
      // Forward to handler
    }
  }
}

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 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 Scanner BufferedInputStream on System.in. This code example stores the Scanner as a class variable so compliant solution ensures 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 a Scanner on System.in, the library would need to be modified so that all code uses the same Scanner instead of creating separate ones.the BufferedInputStream by declaring it as a class variable:

import java.util.Scanner;

public final class InputLibrary {

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

  public static intchar getIntgetChar() throws EOFException, IOException {
    int returninput = in.nextIntread();
    if  }

  public static double getDouble() {
    return in.nextDouble()(input == -1) {
      throw new EOFException();
    }
    in.skip(1); // This statement is to advance to the next line.
                // The noncompliant code example deceptively
                // appeared to work without it (in some cases).
    return (char) input;
  }

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

Risk Assessment

}

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

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

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

Risk Assessment

Creating multiple buffered wrappers around an InputStream can cause unexpected program behavior when the InputStream is redirectedCreating multiple Scanners on System.in can crash the program when System.in is re-directed.

Automated Detection

TODO

Related Vulnerabilities

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

References

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

Bibliography

...

Image Added Image Added Image Added Wiki Markup\[[API 06|AA. Java References#API 06]\] [class Scanner|http://java.sun.com/javase/6/docs/api/java/lang/Scanner.html]