This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Command Injection"

From OWASP
Jump to: navigation, search
Line 106: Line 106:
  
 
[[Category:Input Validation]]
 
[[Category:Input Validation]]
 +
 +
[[Category:Code Snippet]]
  
 
[[Category:C]]
 
[[Category:C]]

Revision as of 13:56, 8 June 2006


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.

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

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.

Related problems