ABSTRACT

Executing commands that include unvalidated user input can cause an application to execute malicious commands on behalf of an attacker.

EXPLANATION

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, the possibility that an attacker may be able to change the meaning of the command by changing an environment variable or by putting a malicious executable early in 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: The following code is from a web application that allows users access to an interface through which they can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory, the code for which is shown below.


...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to CALL 'SYSTEM'. If an attacker can modify the $PATH variable to point to a malicious binary called make and then execute the application in their environment, the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving them complete control of the system.

REFERENCES

[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