CWE 77

Improper Sanitization of Special Elements used in a Command ('Command Injection')

Weakness ID: 77 (Weakness Class)

Status: Draft

Description

Description Summary

The software constructs all or part of a command using externally-influenced input from an upstream component, but it does not sanitize or incorrectly sanitizes special elements that could modify the intended command when it is sent to a downstream component.

Extended Description

Command injection vulnerabilities typically occur when:

1. Data enters the application from an untrusted source.

2. The data is part of a string that is executed as a command by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Time of Introduction

Architecture and Design
Implementation

Applicable Platforms

Languages

All

Common Consequences

Scope	Effect
Access Control	Command injection allows for the execution of arbitrary commands and code by the attacker.
Integrity	If a malicious user injects a character (such as a semi-colon) that delimits the end of one command and the beginning of another, it may be possible to then insert an entirely new and unrelated command that was not intended to be executed.

Likelihood of Exploit

Very High

Demonstrative Examples

Example 1

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

int main(char* 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.

Example 2

The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies what type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.

(Bad Code)

Example Language: Java

...

String btype = request.getParameter("backuptype");

String cmd = new String("cmd.exe /K \"

c:\\util\\rmanDB.bat "

+btype+

"&&c:\\utl\\cleanup.bat\"")

System.Runtime.getRuntime().exec(cmd);

...

The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Runtime.exec(). Once the shell is invoked, it will happily execute multiple commands separated by two ampersands. If an attacker passes a string of the form "& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3

The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.

(Bad Code)

Example Language: Java

...

String home = System.getProperty("APPHOME");

String cmd = home + INITCMD;

java.lang.Runtime.getRuntime().exec(cmd);

...

The code above allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 4

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.

(Bad Code)

Example Language: Java

...

System.Runtime.getRuntime().exec("make");

...

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 Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then 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 the attacker complete control of the system.

Example 5

The following code is a wrapper around the UNIX command cat which prints the contents of a file to standard out. It is also injectable:

(Bad Code)

Example Language: C

#include <stdio.h>

#include <unistd.h>

int main(int argc, char **argv) {

char cat[] = "cat ";

char *command;

size_t commandLength;

commandLength = strlen(cat) + strlen(argv[1]) + 1;

command = (char *) malloc(commandLength);

strncpy(command, cat, commandLength);

strncat(command, argv[1], (commandLength - strlen(cat)) );

system(command);

return (0);

}

Used normally, the output is simply the contents of the file requested:

$ ./catWrapper Story.txt

When last we left our heroes...

However, if we add a semicolon and another command to the end of this line, the command is executed by catWrapper with no complaint:

(Attack)

$ ./catWrapper Story.txt; ls

When last we left our heroes...

Story.txt

SensitiveFile.txt

PrivateData.db

a.out*

If catWrapper had been set to have a higher privilege level than the standard user, arbitrary commands could be executed with that higher privilege.

Potential Mitigations

Phase: Architecture and Design

If at all possible, use library calls rather than external processes to recreate the desired functionality

Phase: Implementation

If possible, ensure that all external commands called from the program are statically created.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

Run time: Run time policy enforcement may be used in a white-list fashion to prevent use of any non-sanctioned commands.

Assign permissions to the software system that prevents the user from accessing/opening privileged files.

Other Notes

Command injection is a common problem with wrapper programs.

Weakness Ordinalities

Ordinality	Description
Primary	(where the weakness exists independent of other weaknesses)

Relationships

Nature	Type	ID	Name	View(s) this relationship pertains to
ChildOf	Weakness Class	20	Improper Input Validation	Seven Pernicious Kingdoms (primary)700
ChildOf	Weakness Class	74	Failure to Sanitize Data into a Different Plane ('Injection')	Development Concepts (primary)699 Research Concepts (primary)1000
ChildOf	Category	713	OWASP Top Ten 2007 Category A2 - Injection Flaws	Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOf	Category	722	OWASP Top Ten 2004 Category A1 - Unvalidated Input	Weaknesses in OWASP Top Ten (2004)711
ChildOf	Category	727	OWASP Top Ten 2004 Category A6 - Injection Flaws	Weaknesses in OWASP Top Ten (2004) (primary)711
ParentOf	Weakness Base	78	Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection')	Development Concepts (primary)699 Research Concepts (primary)1000
ParentOf	Weakness Base	88	Argument Injection or Modification	Development Concepts (primary)699 Research Concepts (primary)1000
ParentOf	Weakness Base	89	Improper Sanitization of Special Elements used in an SQL Command ('SQL Injection')	Development Concepts (primary)699 Research Concepts (primary)1000
ParentOf	Weakness Base	90	Failure to Sanitize Data into LDAP Queries ('LDAP Injection')	Development Concepts (primary)699 Research Concepts (primary)1000
ParentOf	Weakness Base	624	Executable Regular Expression Error	Development Concepts (primary)699 Research Concepts (primary)1000

Causal Nature

Explicit

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Command Injection
CLASP			Command injection
OWASP Top Ten 2007	A2	CWE More Specific	Injection Flaws
OWASP Top Ten 2004	A1	CWE More Specific	Unvalidated Input
OWASP Top Ten 2004	A6	CWE More Specific	Injection Flaws

Related Attack Patterns

CAPEC-ID	Attack Pattern Name	(CAPEC Version: 1.4)
15	Command Delimiters
23	File System Function Injection, Content Based
43	Exploiting Multiple Input Interpretation Layers
75	Manipulating Writeable Configuration Files
6	Argument Injection
11	Cause Web Server Misclassification
76	Manipulating Input to File System Calls

References

G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. February 2004.

Content History

Submissions
Submission Date	Submitter	Organization	Source
	7 Pernicious Kingdoms		Externally Mined

Modifications
Modification Date	Modifier	Organization	Source
2008-07-01	Eric Dalci	Cigital	External
2008-07-01	updated Time of Introduction
2008-08-15		Veracode	External
2008-08-15	Suggested OWASP Top Ten 2004 mapping
2008-09-08	CWE Content Team	MITRE	Internal
2008-09-08	updated Common Consequences, Relationships, Other Notes, Taxonomy Mappings, Weakness Ordinalities
2009-05-27	CWE Content Team	MITRE	Internal
2009-05-27	updated Demonstrative Examples, Name
2009-07-27	CWE Content Team	MITRE	Internal
2009-07-27	updated Demonstrative Examples, Description, Name
2009-10-29	CWE Content Team	MITRE	Internal
2009-10-29	updated Common Consequences, Description, Other Notes, Potential Mitigations
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Command Injection

2009-05-27	Failure to Sanitize Data into a Control Plane (aka 'Command Injection')

2009-07-27	Failure to Sanitize Data into a Control Plane ('Command Injection')

CWE 77

COMPANY

STANDARDS

RECENT POSTS

MENU