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 "Process Control"

From OWASP
Jump to: navigation, search
(Contents provided by Fortify.)
Line 2: Line 2:
 
{{Template:Fortify}}
 
{{Template:Fortify}}
  
==Abstract==
+
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 +
 
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 +
 
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 +
 
 +
[[ASDR Table of Contents]]
 +
__TOC__
  
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
 
  
 
==Description==
 
==Description==
 +
 +
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
  
 
Process control vulnerabilities take two forms:
 
Process control vulnerabilities take two forms:
Line 19: Line 27:
 
# By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.  
 
# By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.  
  
==Examples ==
+
 
 +
==Risk Factors==
 +
 
 +
TBD
 +
 
 +
==Examples==
  
 
===Example 1===
 
===Example 1===
Line 64: Line 77:
 
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.
 
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 Threats==
+
==Related [[Attacks]]==
 +
 
 +
* [[Command Injection]]
 +
 
 +
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 
 +
==Related [[Controls]]==
 +
 
 +
* [[:Category:Input Validation]]
 +
 
 +
 
 +
==Related [[Technical Impacts]]==
 +
 
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:
 +
 
 +
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
 +
* http://www.link1.com
 +
* [http://www.link2.com Title for the link2]
 +
 
 +
[[Category:FIXME|add links
 +
 
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 
 +
Availability Vulnerability
 +
 
 +
Authorization Vulnerability
 +
 
 +
Authentication Vulnerability
 +
 
 +
Concurrency Vulnerability
 +
 
 +
Configuration Vulnerability
 +
 
 +
Cryptographic Vulnerability
 +
 
 +
Encoding Vulnerability
  
==Related Attacks==
+
Error Handling Vulnerability
  
[[Command Injection]]
+
Input Validation Vulnerability
  
==Related Vulnerabilities==
+
Logging and Auditing Vulnerability
  
==Related Countermeasures==
+
Session Management Vulnerability]]
  
[[:Category:Input Validation]]
+
__NOTOC__
  
==Categories==
 
  
 +
[[Category:OWASP ASDR Project]]
 
[[Category:Input Validation Vulnerability]]
 
[[Category:Input Validation Vulnerability]]
 
[[Category:Java]]
 
[[Category:Java]]
 
[[Category:Code Snippet]]
 
[[Category:Code Snippet]]

Revision as of 13:02, 30 September 2008

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

This article includes content generously donated to OWASP by MicroFocus Logo.png

Last revision (mm/dd/yy): 09/30/2008

Vulnerabilities Table of Contents

ASDR Table of Contents


Description

Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.

Process control 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.

We will first consider the first scenario, the possibility that an attacker may be able to control the command that is executed. Process control vulnerabilities of this type occur when:

  1. Data enters the application from an untrusted source.
  2. The data is used as or as part of a string representing a command that is executed by the application.
  3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.


Risk Factors

TBD

Examples

Example 1

The following Java code from a system utility uses thesystem 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.

	...
	String home = System.getProperty("APPHOME");
	String cmd = home + INITCMD; 
	java.lang.Runtime.getRuntime().exec(cmd);
	...

The code in Example 1 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 2

The following code is from an administrative web application designed 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.

	...
	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 first 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 C 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 Attacks

Related Vulnerabilities

Related Controls


Related Technical Impacts


References

Note: A reference to related CWE or CAPEC article should be added when exists. Eg: