Command Injection

This is an Attack. To view all attacks, please see the Attack Category page.

Abstract

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

Overview

Command injection problems are a subset of injection problem, in which the process is tricked into calling external processes of the attackers choice through the injection of control-plane data into the data plane.

Command injection attacks 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 first scenario, in which an attacker explicitly controls the command that is executed. Command injection vulnerabilities of this type 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.

Consequences

• Access control: Command injection allows for the execution of arbitrary commands and code by the attacker.

Exposure period

• Design: It may be possible to find alternate methods for satisfying functional requirements than calling external processes. This is minimal.

• Implementation: Exposure for this issue is limited almost exclusively to implementation time. Any language or platform is subject to this flaw.

Platform

• Language: Any

• Platform: Any

Required resources

Any

Severity

High

Likelihood of exploit

Very High

Avoidance and mitigation

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

• Implementation: Ensure that all external commands called from the program are statically created, or - if they must take input from a user - that the input and final line generated are vigorously white-list checked.

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

Discussion

Command injection is a common problem with wrapper programs. Often, parts of the command to be run are controllable by the end user. If a malicious user injects a character (such as a semi-colon) that delimits the end of one command and the beginning of another, he may then be able to insert an entirely new and unrelated command to do whatever he pleases.

The most effective way to deter such an attack is to ensure that the input provided by the user adheres to strict rules as to what characters are acceptable. As always, white-list style checking is far preferable to black-list style checking.

Examples

Example 1

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

#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:

$ ./catWrapper "Story.txt; ls"
When last we left our heroes...
Story.txt               doubFree.c              nullpointer.c
unstosig.c              www*                    a.out*
format.c                strlen.c                useFree*
catWrapper*             misnull.c               strlength.c                useFree.c               commandinjection.c      nodefault.c             trunc.c                 writeWhatWhere.c

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

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.

	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 3

The following code from a privileged program uses the environment variable $APPHOME to determine the application's installation directory and then executes an initialization script in that directory.

	...
	char* home=getenv("APPHOME"); 	
	char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
	if (cmd) { 
		strcpy(cmd,home);
		strcat(cmd,INITCMD);
		execl(cmd, NULL);
	}
	...

As in Example 2, the code in this example allows an attacker to execute arbitrary commands with the elevated privilege of the application. In this example, the attacker can modify the environment variable $APPHOME to specify a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, by controlling the environment variable the attacker can fool the application into running malicious code.

The attacker is using the environment variable to control the command that the program invokes, so the effect of the environment is explicit in this example. We will now turn our attention to what can happen when the attacker can change the way the command is interpreted.

Example 4

The code below 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");

Unlike the previous examples, the command in this example is hardcoded, so an attacker cannot control the argument passed to system(). However, since the program does not specify an absolute path for make and does not scrub any 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.

The environment plays a powerful role in the execution of system commands within programs. Functions like 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.

Related problems

• Injection problem

Related Attacks

OS Command Injection

Related Countermeasures

• Category:Input Validation

Categories

This article includes content generously donated to OWASP by