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 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
/ 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
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:
The command executed is actually two commands:
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
The attacker can supply the same command shown in the previous noncompliant code example with similar effects. The command executed is actually
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.
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
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 scalable solution is to read all the permitted directories from a properties file into a
Compliant Solution (Avoid
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.
Passing untrusted, unsanitized data to the
Runtime.exec() method can result in command and argument injection attacks.
|The Checker Framework|
|Tainting Checker||Trust and security errors (see Chapter 8)|
|OS commands should not be vulnerable to injection attacks|
|SEI CERT Perl Coding Standard||IDS34-PL. Do not pass untrusted, unsanitized data to a command interpreter|
CWE-78, Improper Neutralization of Special Elements Used in an OS Command ("OS Command Injection")
Android Implementation Details
Runtime.exec() can be called from Android apps to execute operating system commands.
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)|