IDS06-J. Prevent OS Command Injection

OS command injection vulnerabilities occur when an application does not sanitize externally obtained input and allows 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.

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

  
String programName = System.getProperty("program.name");
if (programName != null){ 
  // 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.

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.

  
// programName can be 'ProgramName1 || ProgramName2'  
Process proc = runtime.exec("/bin/sh" + programName);  // "cmd.exe /C" on Windows

Compliant Solution

This compliant solution restricts the programs that a privileged application can invoke when using user controlled inputs.

Process proc;
int filename = Integer.parseInt(System.getproperty("program.name")); // only allow integer choices
Runtime runtime = Runtime.getRuntime();

switch(filename) {
  case 1: 
    proc = runtime.exec("hardcoded\program1"); 
    break; // Option 1
  case 2: 
    proc = runtime.exec("hardcoded\program2"); 
    break; // Option 2
  default:
    System.out.println("Invalid option!");
    break; 
}

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

Automated Detection

TODO

Related Vulnerabilities

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

Other languages

This rule appears in the C Secure Coding Standard as ENV03-C. Sanitize the environment when invoking external programs.

This rule appears in the C++ Secure Coding Standard as ENV03-CPP. Sanitize the environment when invoking external programs.

References

[[OWASP 2005]] Reviewing Code for OS Injection
[[Chess 2007]] Chapter 5: Handling Input, "Command Injection"
[[MITRE 2009]] CWE ID 78 "Failure to Preserve OS Command Structure (aka 'OS Command Injection')"

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