Page History

External programs are commonly invoked to perform a function required by the overall system. This practice is a form of reuse and might even be considered a crude form of component-based software engineering. Command and argument injection vulnerabilities occur when an application fails to sanitize untrusted input and uses it in the execution of external programs.

Every Java application has a single instance of class Runtime that allows the application to interface with the environment in which the application is running. The current runtime can be obtained from the Runtime.getRuntime() method. The semantics of Runtime.exec() are poorly defined, so it 's is best not to rely on its behavior any more than necessary. It will invoke , but typically it invokes the command directly without a shell. If you want a shell, you can use /bin/sh , -c on POSIX or cmd.exe on Windows. The variants of exec() that take the command line as a single String string split it with using a StringTokenizer. On Windows, these tokens are concatenated back into a single argument string somewhere before being executed.

Consequently, command injection doesn't work attacks cannot succeed unless a command interpreter is explicitly invoked. However, particularly on Windows, there can be vulnerabilities where argument injection attacks can occur when arguments have spaces, double quotes, and so forth, or when they start with a - or / to indicate a switch.

This is a specific instance of the rule IDS01-J. Sanitize untrusted data passed across a trust boundary. Any string data that originates from outside the program's trust boundary must be sanitized before being executed as a command on the current platform.

Noncompliant Code Example (Windows)

...

This noncompliant code example provides a directory listing using the dir command. It accomplishes this by is implemented using Runtime.exec() to invoke the Windows dir command.

Code Block
bgColor #FFcccc
import java.io.InputStream; class DirList { public static void main(String[] args) throws Exception { String dir = System.getProperty("dir"); Runtime rt = Runtime.getRuntime(); Process proc = rt.exec("cmd.exe /C dir " + dir); int result = proc.waitFor(); if (result != 0) { System.out.println("process error: " + result); } InputStream in = (result == 0) ? proc.getInputStream() : proc.getErrorStream(); int c; while ((c = in.read()) != -1) { System.out.print((char) c); } } }

Because Runtime.exec() receives unsanitized data originating from the environment (see rule ENV06-J. Provide a trusted environment and sanitize all inputs), this code is susceptible to a command injection attack.

An attacker can exploit this program using the following command:

Code Block
java -Ddir='dummy & echo bad' Java

the The command executed is actually two commands:

Code Block
cmd.exe /C dir dummy & echo bad

which first attempts to list a nonexistent dummy folder , and then prints bad to the console.

Noncompliant Code Example (POSIX)

This noncompliant code example provides the same functionality , but uses the POSIX ls command. The only difference from the Windows version is the argument passed to proc Runtime.exec().

  
import java.io.InputStream;

class DirList {

  public static void main(String[] args) throws Exception {
    String dir = System.getProperty("dir");
    Runtime rt = Runtime.getRuntime();
    Process proc = rt.exec(new String[] {"sh", "-c", "ls " + dir});
    int result = proc.waitFor();
    if (result != 0) {
      System.out.println("process error: " + result);
    }
    InputStream in = (result == 0) ? proc.getInputStream() :
                                     proc.getErrorStream();
    int c;
    while ((c = in.read()) != -1) {
      System.out.print((char) c);
    }
  }
}

The attacker can supply the same command , with the same effects as aboveshown in the previous noncompliant code example with similar effects. The command executed is actually:

sh -c 'ls dummy & echo bad'

Compliant Solution (Sanitization)

This compliant solution solution sanitizes the untrusted user input by permitting only a handful small group of correct characters to appearwhitelisted characters in the argument that will be passed to Runtime.exec(); all other characters are excluded.

// ...
if (!Pattern.matches("[0-9A-Za-z@.]+", dir)) {
  // Handle error
}
// ...

Although this it is a compliant solution, the sanitization method is weak because it will reject this sanitization approach rejects valid directories. Also, because the command interpreter invoked is system dependent, it is difficult to say establish that this solution will not allow prevents command injection injections on every possible platform in on which a Java program might run.

Compliant Solution (Restricted User Choice)

This compliant solution prevents command injection by passing only passing trusted strings to Runtime.exec(). While the The user has control over which string gets is used , the user cannot send strings but cannot provide string data directly to Runtime.exec().

// ...
String dir = null;

int number = Integer.parseInt(System.getpropertygetProperty("dir")); // onlyOnly allow integer choices
switch (number) {
  case 1: 
    dir = "data1";
    break; // Option 1
  case 2: 
    dir = "data2";
    break; // Option 2
  default: // invalidInvalid
    break; 
}
if (dir == null) {
  // handleHandle error

}

This compliant solution hard codes the directories that may be listed.

This solution can quickly become unmanageable if you have many available directories. A more extensible scalable solution is to read all the email addresses permitted directories from a properties file into a java.util.Properties object.

Compliant Solution (Avoid Runtime.exec())

When the task performed by executing a system command can be accomplished by some other means, it is almost always advisable to do so. This compliant solution uses the File.list() method to provide a directory listing, thereby preventing command injectioneliminating the possibility of command or argument injection attacks.

import java.io.File;

class DirList {
  public static void main(String[] args) throws Exception {
    File dir = new File(System.getProperty("dir"));
    if (!dir.isDirectory()) {
      System.out.println("Not a directory");
    } else {
      for (String file : dir.list()) {
        System.out.println(file);
      }
    }
  }
}

Risk Assessment

Pass Passing untrusted, unsanitized data to the Runtime.exec() method can result in command and argument injection attacks.

Automated Detection

Related Vulnerabilities

Examples of related vulnerabilities include:

Related Vulnerabilities

...

...

...

Related Guidelines

Android Implementation Details

Runtime.exec() can be called from Android apps to execute operating system commands.

Bibliography

[Chess 2007]	Chapter 5, "Handling Input," section "Command Injection"
[OWASP 2005]	A Guide to Building Secure Web Applications and Web Services
[Permissions 2008]	Permissions in the Java™ SE 6 Development Kit (JDK)
[Seacord 2015]	Image Added IDS07-J. Do not pass untrusted, unsanitized data to the Runtime.exec() method LiveLesson

...

Image Added Image Added Image Added

...

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

Bibliography

\[[Chess 2007|AA. Bibliography#Chess 07]\] Chapter 5: Handling Input, "Command Injection"
\[[MITRE 2009|AA. Bibliography#MITRE 09]\] [CWE ID 78|http://cwe.mitre.org/data/definitions/78.html] "Failure to Preserve OS Command Structure (aka 'OS Command Injection')"
\[[OWASP 2005|AA. Bibliography#OWASP 05]\] [Reviewing Code for OS Injection|http://www.owasp.org/index.php/Reviewing_Code_for_OS_Injection]
\[[Permissions 2008|AA. Bibliography#Permissions 08]\] [Permissions in the Java™ SE 6 Development Kit (JDK)|http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html], Sun Microsystems, Inc. (2008)

IDS05-J. Do not log unsanitized user input      Image Removed      IDS13-J. Do not assume every character in a string is the same size