External programs are commonly invoked to perform a function required by the overall system. This 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.
exec() built-in function is the standard mechanism for executing system commands; it is a wrapper around the POSIX
exec family of system calls. The
system() built-in function is similar to
exec, but it takes a single string, whereas
exec()takes a list. The
qx operator, often represented by encasing a command in backquotes (
``), can also be used to execute an arbitrary command. Finally, the
open() function can also execute commands in a subprocess and either send data to them or fetch data from them (but not both).
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.
This rule is a specific instance of IDS33-PL. 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 (
This noncompliant code example tries to list a directory specified by the user. It safely uses the three-argument
open() command, as required by IDS31-PL. Do not use the two-argument form of open().
The program also works properly when given a valid directory as an argument:
But it can also have unintended consequences, as in this case, if an attacker injects an arbitrary command to be executed by the call to
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
open(); all other characters are excluded.
This code properly rejects shell commands:
However, this code also rejects valid directories if they contain characters not in the whitelist regex.
Compliant Solution (Shell Avoidance)
This compliant solution again sanitizes the untrusted user input. However, it uses the multi-arg form of
The perlfunc manpages states, regarding all but the first two arguments to
If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is "/bin/sh -c" on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to "execvp," which is more efficient.
So this form of
open() is preferable if your platform's shell might be set up incorrectly or maliciously.
Compliant Solution (Restricted Choice)
This compliant solution prevents command injection by passing only trusted strings to
open(). 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 an external file into a hash object, and the external file must be kept secure from untrusted users.
Compliant Solution (Avoid Interpreters)
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
closedir() subroutines to provide a directory listing, eliminating the possibility of command or argument injection attacks.
Noncompliant Code Example (
US-CERT Vulnerability #583020 describes Perl code that invoked the
system() built-ig function without sanitizing its argument:
An attacker who could control the arguments to the
do() subroutine could cause the code to invoke arbitrary shell commands. This code also violates DCL31-PL. Do not overload reserved keywords or subroutines.
Compliant Solution (
This code was mitigated by adding a regex to make sure that only a single character supplied by the user could be added to the
$do_call variable before passing it to
This code still violates DCL31-PL. Do not overload reserved keywords or subroutines; it is shown here for historical accuracy.
Using deprecated or obsolete classes or methods in program code can lead to erroneous behavior.
|Taint mode||Insecure dependency in (system|piped open)|