Page History

OS command 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 does not sanitize externally obtained fails to sanitize untrusted input and allows uses it in the execution of arbitrary system commands (with carefully chosen arguments) or an external program.

Noncompliant Code Example

A weakness in a privileged program caused by relying on untrusted sources such as the environment (guideline ENV06-J. Provide a trusted environment and sanitize all inputs) can result in the execution of a command or a program that has more privileges than those possessed by a typical user. This noncompliant code example shows such a variant of the OS command injection vulnerability.

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 is best not to rely on its behavior any more than necessary, 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 split it using a StringTokenizer. On Windows, these tokens are concatenated back into a single argument string before being executed.

Consequently, command injection attacks cannot succeed unless a command interpreter is explicitly invoked. However, 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.

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 is implemented using Runtime.exec() to invoke the Windows dir commandWhen the single argument version of the Runtime.exec() method is invoked, the arguments are parsed by a StringTokenizer into separate tokens. Consequently, any command separators maliciously inserted into the argument do not delimit the original command and an adversary is unable to proceed with executing arbitrary system commands. However, this code is still vulnerable as an attacker can easily invoke an external (privileged) program, in the presence of a lax security policy.

class DirList {
  public static void main(String[] args) throws Exception {
    String programNamedir = System.getProperty("program.name");
if (programName("dir");
    Runtime rt = Runtime.getRuntime();
    Process proc = rt.exec("cmd.exe /C dir " + dir);
    int result = proc.waitFor();
    if (result != null0) {
      System.out.println("process error: " + result);
    }
    InputStream in = // Runs user controlled program 
  Runtime runtime = Runtime.getRuntime();
  Process proc = runtime.exec(programName); 
}

Noncompliant Code Example

This noncompliant code example demonstrates a less likely, though more pernicious form of OS command injection. The program spawns a shell (POSIX based platforms) or a command prompt (Windows) and allows passing arguments to external programs. Sometimes the shell or prompt is used to set an environment variable to a user defined value from within the program. The programName string is expected to hold the program's name, as well as the arguments.

(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, this code is susceptible to a command injection attack.

An attacker can exploit this program using the following command:

java -Ddir='dummy & echo bad' Java

The command executed is actually two commands:

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 Runtime.exec()An adversary can terminate the command with a command separator (such as '&&' and '||') to execute arbitrary commands. For example, the output of the program can be piped to a sensitive file for the purpose of causing a denial of service, or even worse, redirecting some sensitive output to a non sensitive location.

class DirList {
  public static void main(String[] args) throws 
// programName can be 'ProgramName1 || ProgramName2'  
Exception {
    String dir = System.getProperty("dir");
    Runtime rt = Runtime.getRuntime();
    Process proc = runtimert.exec("/bin/sh" + programName);  // "cmd.exe /C" on Windows

Compliant Solution

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 shown 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 sanitizes the untrusted user input by permitting only a small group of whitelisted 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 it is a compliant solution, this sanitization approach rejects valid directories. Also, because the command interpreter invoked is system dependent, it is difficult to establish that this solution prevents command injections on every platform on which a Java program might run.

Compliant Solution (Restricted User Choice)

This compliant solution prevents command injection by passing only trusted strings to Runtime.exec(). The user has control over which string is used but cannot provide string data directly to Runtime.exec()This compliant solution restricts the programs that a privileged application can invoke when using user controlled inputs.

Process proc// ...
String dir = null;

int filenamenumber = Integer.parseInt(System.getpropertygetProperty("program.namedir")); // onlyOnly allow integer choices
Runtime runtime = Runtime.getRuntime();

switch(filenameswitch (number) {
  case 1: 
    procdir = runtime.exec("hardcoded\program1"); "data1";
    break; // Option 1
  case 2: 
    procdir = runtime.exec("hardcoded\program2"); "data2";
    break; // Option 2
  default: // Invalid
     System.out.println("Invalid option!");break; 
}
if (dir == null) {
  // Handle break; error
}

This also prevents exposure of the file system structure.

Compliant Solution

An alternative is to read the file names from a source existing in a secure directory, inaccessible to an attacker. The security policy file may grant permissions to the application to execute files from a specific directory. The security manager must be used when running the application. (See guideline ENV02-J. Create a secure sandbox using a Security Manager.) The security manager's checkExec(String cmd) method allows checking whether the program has the permissions to create the subprocess and execute the external program.

The security policy file must grant the {{java.io.FilePermission}} as follows: if {{cmd}} is an absolute path, {{java.io.FilePermission "\{cmd\}", "execute"}} ; else {{java.io.FilePermission "-", "execute";}} \[[Permissions 2008|AA. Bibliography#Permissions 08]\]. However, in the latter case, all programs can be freely executed if the permission is granted. Consequently, permissions should be restricted per file only, by giving absolute paths. 

Risk Assessment

OS command injection can cause arbitrary programs to be executed.

compliant solution hard codes the directories that may be listed.

This solution can quickly become unmanageable if you have many available directories. A more scalable solution is to read all the 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, eliminating 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

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

Automated Detection

...

TODO

Related Vulnerabilities

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

Other languages

...

Tool	Version	Checker	Description
The Checker Framework	Include Page The Checker Framework_V The Checker Framework_V	Tainting Checker	Trust and security errors (see Chapter 8)
CodeSonar	Include Page CodeSonar_V CodeSonar_V	JAVA.IO.INJ.COMMAND	Command Injection (Java)
Coverity	7.5	OS_CMD_INJECTION	Implemented
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	CERT.IDS07.EXEC	Do not use 'Runtime.exec()'
SonarQube	Include Page SonarQube_V SonarQube_V	S2076	OS commands should not be vulnerable to injection attacks

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

Bibliography

\[[OWASP 2005|AA. Bibliography#OWASP 05]\] [Reviewing Code for OS Injection|http://www.owasp.org/index.php/Reviewing_Code_for_OS_Injection]
\[[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')"

IDS05-J. Library methods should validate their parameters      Input Validation and Data Sanitization (IDS)      IDS07-J. Prevent SQL Injection