Executing commands without specifying an absolute path could allow an attacker to execute a malicious binary by changing $PATH
or other aspects of the program's execution environment.
Command injection vulnerabilities take two forms:
- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.
- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.
In this case we are primarily concerned with the second scenario, in which an attacker can change the meaning of the command by changing an environment variable or by inserting a malicious executable early on the search path. Command injection vulnerabilities of this type occur when:
1. An attacker modifies an application's environment.
2. The application executes a command without specifying an absolute path or verifying the binary being executed.
3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.
Example 1: This example demonstrates what can happen when the attacker can change how a command is interpreted. The code is from a web-based CGI utility that allows users to change their passwords. The password update process under NIS includes running make
in the /var/yp
directory. Note that since the program updates password records, it has been installed setuid root
.
The program invokes make
as follows:
system("cd /var/yp && make &> /dev/null");
system()
. However, since the program does not specify an absolute path for make
and does not scrub its environment variables prior to invoking the command, the attacker can modify their $PATH
variable to point to a malicious binary named make
and execute the CGI script from a shell prompt. And since the program has been installed setuid root
, the attacker's version of make
now runs with root
privileges. system()
and exec()
use the environment of the program that calls them, and therefore attackers have a potential opportunity to influence the behavior of these calls.
[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A1 Injection
[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A2 Injection Flaws
[3] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A6 Injection Flaws
[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3570 CAT I
[5] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 77, CWE ID 78
[6] Standards Mapping - SANS Top 25 2010 - (SANS 2010) Insecure Interaction - CWE ID 078
[7] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 116
[8] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) OS Commanding
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.6