You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

OS command injection vulnerabilities occur when an application does not sanitize externally obtained inputs 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 (See ENV35-J. Provide a trusted environment and sanitize all inputs), can result in the execution of a command or a program which has more privileges than those possessed by a typical user. This code snippet shows such a vulnerability and can be best described as a variant of OS command injection. 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 will not delimit the original command and an adversary will be unable to proceed with executing arbitrary system commands. This code is however, equally vulnerable as an attacker can easily invoke an external (privileged) program, despite the presence of a security manager.

  
// security manager check
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

A less likely, though more pernicious form of OS command injection is portrayed in this noncompliant example. The program spawns a shell (*nix) or a command prompt (Windows) and allows passing arguments to external programs. Sometimes the shell or prompt is just used to set an environment variable to a user defined value. 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 '||') or cause the output of the program to be piped to a sensitive file for the purpose of causing a denial of service (privileged program), or even worse, redirect 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; 
}

Risk Assessment

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

MSC32- J

high

probable

medium

P12

L1

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 05]] Reviewing Code for OS Injection
[[Chess 07]] Chapter 5: Handling Input, "Command Injection"
[[MITRE 09]] CWE ID 78 "Failure to Preserve OS Command Structure (aka 'OS Command Injection')"


MSC31-J. Never hardcode sensitive information      49. Miscellaneous (MSC)      MSC33-J. Prevent against SQL Injection

  • No labels