157
Strategy = Environment Hardening
Run the code in an environment that performs automatic taint propagation and prevents any
command execution that uses tainted variables, such as Perl's "-T" switch. This will force the
program to perform validation steps that remove the taint, although you must be careful to
correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted
(see CWE-183 and CWE-184).
Phase: Implementation
Ensure that error messages only contain minimal details that are useful to the intended audience
and no one else. The messages need to strike the balance between being too cryptic (which
can confuse users) or being too detailed (which may reveal more than intended). The messages
should not reveal the methods that were used to determine the error. Attackers can use detailed
information to refine or optimize their original attack, thereby increasing their chances of success.
If errors must be captured in some detail, record them in log messages, but consider what
could occur if the log messages can be viewed by attackers. Highly sensitive information such
as passwords should never be saved to log files. Avoid inconsistent messaging that might
accidentally tip off an attacker about internal state, such as whether a user account exists or not.
In the context of OS Command Injection, error information passed back to the user might reveal
whether an OS command is being executed and possibly which command is being used.
Phase: Operation
Strategy = Sandbox or Jail
Use runtime policy enforcement to create an allowlist of allowable commands, then prevent
use of any command that does not appear in the allowlist. Technologies such as AppArmor are
available to do this.
Phase: Operation
Strategy = Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial
in cases in which the code cannot be fixed (because it is controlled by a third party), as an
emergency prevention measure while more comprehensive software assurance measures are
applied, or to provide defense in depth.
Effectiveness = Moderate
An application firewall might not cover all possible input vectors. In addition, attack techniques
might be available to bypass the protection mechanism, such as using malformed inputs that can
still be processed by the component that receives those inputs. Depending on functionality, an
application firewall might inadvertently reject or modify legitimate requests. Finally, some manual
effort may be required for customization.
Phase: Architecture and Design
Phase: Operation
Strategy = Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks
[REF-76]. If possible, create isolated accounts with limited privileges that are only used for a
single task. That way, a successful attack will not immediately give the attacker access to the
rest of the software or its environment. For example, database applications rarely need to run as
the database administrator, especially in day-to-day operations.
Phase: Operation
Phase: Implementation
Strategy = Environment Hardening
CWE Version 4.14
CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command
Injection')
CWE-78: Improper Neutralization of Special Elements
used in an OS Command ('OS Command Injection') 158
When using PHP, configure the application so that it does not use register_globals. During
implementation, develop the application so that it does not rely on this feature, but be wary of
implementing a register_globals emulation that is subject to weaknesses such as CWE-95,
CWE-621, and similar issues.
Demonstrative Examples
Example 1:
This example code intends to take the name of a user and list the contents of that user's home
directory. It is subject to the first variant of OS command injection.
Example Language: PHP (Bad)
$userName = $_POST["user"];
$command = 'ls -l /home/' . $userName;
system($command);
The $userName variable is not checked for malicious input. An attacker could set the $userName
variable to an arbitrary OS command such as:
Example Language: (Attack)
;rm -rf /
Which would result in $command being:
Example Language: (Result)
ls -l /home/;rm -rf /
Since the semi-colon is a command separator in Unix, the OS would first execute the ls command,
then the rm command, deleting the entire file system.
Also note that this example code is vulnerable to Path Traversal (CWE-22) and Untrusted Search
Path (CWE-426) attacks.
Example 2:
The following simple program accepts a filename as a command line argument and displays the
contents of the file back to the user. The program is installed setuid root because it is intended for
use as a learning tool to allow system administrators in-training to inspect privileged system files
without giving them the ability to modify them or damage the system.
Example Language: C (Bad)
int main(int argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}
Because the program runs with root privileges, the call to system() also executes with root
privileges. If a user specifies a standard filename, the call works as expected. However, if an
attacker passes a string of the form ";rm -rf /", then the call to system() fails to execute cat due to a
lack of arguments and then plows on to recursively delete the contents of the root partition.
Note that if argv[1] is a very long argument, then this issue might also be subject to a buffer
overflow (CWE-120).
Example 3:
This example is a web application that intends to perform a DNS lookup of a user-supplied domain
name. It is subject to the first variant of OS command injection.
CWE Version 4.14
CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command
Injection')
CWE-78: Improper Neutralization of Special Elements
used in an OS Command ('OS Command Injection')