Kingdom: Input Validation and Representation
Input validation and representation problems ares caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input. The issues include: "Buffer Overflows," "Cross-Site Scripting" attacks, "SQL Injection," and many others.
Command Injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker may be able to control 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 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.
Example 1: The following code from a system utility uses the registry key
The code in
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
The problem here is that the program does not do any validation on the
Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a
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
- 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, the possibility that an attacker may be able to control 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 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.
Example 1: The following code from a system utility uses the registry key
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.
...
CALL FUNCTION 'REGISTRY_GET'
EXPORTING
KEY = 'APPHOME'
IMPORTING
VALUE = home.
CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...
The code in
Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the registry entry APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the registry, if an attacker can control the value of the registry key 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 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 the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.
...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.
CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
EXPORTING
commandname = cmd_exe
long_params = cmd_string
EXCEPTIONS
no_permission = 1
command_not_found = 2
parameters_too_long = 3
security_risk = 4
OTHERS = 5.
...
The problem here is that the program does not do any validation on the
backuptype parameter read from the user. Typically the function module SXPG_COMMAND_EXECUTE_LONG 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 CALL 'SYSTEM'. After the shell is invoked, it will allow for the execution of 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 is from a web application that provides an interface through which users 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.
...
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 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.References
[1] SAP OSS notes 677435, 686765, 866732, 854060, 1336776, 1520462, 1530983 and related notes.
desc.dataflow.abap.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker may be able to control 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 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.
Example 1: The following code uses input from configuration file to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.
The code in
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
The problem here is that the program does not do any validation on the
Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a
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
- 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, the possibility that an attacker may be able to control 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 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.
Example 1: The following code uses input from configuration file to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.
...
var fs:FileStream = new FileStream();
fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
home = String(fs.readObject(home));
var cmd:String = home + INITCMD;
fscommand("exec", cmd);
...
The code in
Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the contents of the configuration file configStream to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the file, if an attacker can control that value, 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 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 the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.
...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var btype:String = String(params["backuptype"]);
var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
fscommand("exec", cmd);
...
The problem here is that the program does not do any validation on the
backuptype parameter read from the user. Typically the fscommand() 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 fscommnd(). After the shell is invoked, it will allow for the execution of 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 is from a web application that provides an interface through which users 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.
...
fscommand("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
fscommand(). 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.desc.dataflow.actionscript.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker may be able to control 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 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.
Example 1: The following code from a system utility uses the system property
The code in
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
The problem here is that the program does not do any validation on
Example 3: The following code is from a web application that gives users access to an interface through which they can update their password on the system. Part of the process for updating passwords in this network environment is to run an
The problem here is that the program does not specify an absolute path and fails to clean its environment prior to executing the call to
- 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, the possibility that an attacker may be able to control 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 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.
Example 1: 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.
...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...
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 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 the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.
...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
+ btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...
The problem here is that the program does not do any validation on
BackupTypeField. Typically the Process.Start() 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 Process.Start(). After the shell is invoked, it will allow for the execution of 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 is from a web application that gives users access to an interface through which they can update their password on the system. Part of the process for updating passwords in this network environment is to run an
update.exe command, as follows:
...
Process.Start("update.exe");
...
The problem here is that the program does not specify an absolute path and fails to clean its environment prior to executing the call to
Process.start(). If an attacker can modify the $PATH variable to point to a malicious binary called update.exe 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 update.exe will now be run with these privileges, possibly giving the attacker complete control of the system.desc.dataflow.dotnet.command_injection
Abstract
Executing commands that include unvalidated user input can cause an application to act 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 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.
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
Because the program runs with
Example 2: The following code from a privileged program uses the environment variable
As in
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 may change the way the command is interpreted.
Example 3: The following code is from a web-based CGI utility that allows users to change their passwords. The password update process under NIS includes running
The program invokes
Unlike the previous examples, the command in this example is hardcoded, so an attacker cannot control the argument passed to
On Windows, additional risks are present.
Example 4: When invoking
Because of the way
The environment plays a powerful role in the execution of system commands within programs. Functions like
- 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.
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.
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 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 1, the code in this example allows an attacker to execute arbitrary commands with the elevated privilege of the application. In this example, the attacker may 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 may 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 may change the way the command is interpreted.
Example 3: The following code 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 may 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.On Windows, additional risks are present.
Example 4: When invoking
CreateProcess() either directly or via a call to one of the functions in the _spawn() family, care must be taken when there is a space in an executable or path.
...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...
Because of the way
CreateProcess() parses spaces, the first executable the operating system will try to execute is Program.exe, not MyApplication.exe. Therefore, if an attacker is able to install a malicious application called Program.exe on the system, any program that incorrectly calls CreateProcess() using the Program Files directory will run this application instead of the intended one.The environment plays a powerful role in the execution of system commands within programs. Functions like
system(), exec(), and CreateProcess() use the environment of the program that calls them, and therefore attackers have a potential opportunity to influence the behavior of these calls.desc.dataflow.cpp.command_injection
Abstract
Executing commands without specifying an absolute path can enable an attacker to use the program to execute a malicious binary by changing
$PATH or other aspects of the program's execution environment.Explanation
Command injection vulnerabilities take two forms:
- An attacker can change the command that the program executes: the attacker explicitly controls the command.
- An attacker can control parameters to the program.
- 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, in which an attacker can change the meaning of the command by changing an environment variable or by inserting a malicious executable early on 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 1: This example demonstrates what can happen when the attacker can change how a command is interpreted. The code is from a web-based CGI utility that allows users to change their passwords. The password update process under NIS includes running
The program invokes
The command in this example is hardcoded, so an attacker cannot control the argument passed to
Example 2: The following code uses an environment variable to determine the temporary directory that contains the file to print with the
Similar to the previous example, the command is hardcoded. However, because the program does not specify an absolute path for
- An attacker can change the command that the program executes: the attacker explicitly controls the command.
- An attacker can control parameters to the program.
- 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, in which an attacker can change the meaning of the command by changing an environment variable or by inserting a malicious executable early on 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 1: This example demonstrates what can happen when the attacker can change how a command is interpreted. The code 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 because the program updates password records, it has been installed setuid root.The program invokes
make as follows:
MOVE "cd /var/yp && make &> /dev/null" to command-line
CALL "CBL_EXEC_RUN_UNIT" USING command-line
length of command-line
run-unit-id
stack-size
flags
The command in this example is hardcoded, so an attacker cannot control the argument passed to
CBL_EXEC_RUN_UNIT. However, because the program does not specify an absolute path for make and does not scrub its 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. In addition, because the program has been installed setuid root, the attacker's version of make now runs with root privileges.Example 2: The following code uses an environment variable to determine the temporary directory that contains the file to print with the
pdfprint command.
DISPLAY "TEMP" UPON ENVIRONMENT-NAME
ACCEPT ws-temp-dir FROM ENVIRONMENT-VARIABLE
STRING "pdfprint " DELIMITED SIZE
ws-temp-dir DELIMITED SPACE
"/" DELIMITED SIZE
ws-pdf-filename DELIMITED SPACE
x"00" DELIMITED SIZE
INTO cmd-buffer
CALL "SYSTEM" USING cmd-buffer
Similar to the previous example, the command is hardcoded. However, because the program does not specify an absolute path for
pdfprint, the attacker can modify their $PATH variable to point to a malicious binary. Furthermore, while the DELIMITED SPACE phrases prevent embedded spaces in ws-temp-dir and ws-pdf-filename, there could be shell metacharacters (such as &&) embedded in either.desc.semantic.cobol.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker may be able to control 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 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.
Example 1: The following code allows an attacker to specify arbitrary commands via the
- 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, the possibility that an attacker may be able to control 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 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.
Example 1: The following code allows an attacker to specify arbitrary commands via the
cmd request parameter.
...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
arguments = "/c #var#"
timeout = "1"
variable="mycmd">
</cfexecute>
...
desc.dataflow.cfml.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker can control 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 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.
Example 1: The following code from a system utility uses the system property
The code in
- 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, the possibility that an attacker can control 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 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.
Example 1: 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.
...
final cmd = String.fromEnvironment('APPHOME');
await Process.run(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.desc.dataflow.dart.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 the command.
- 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, the possibility that an attacker can control the executed command. Command injection 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 that represents a command the application executes.
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 runs a user-controller command.
- An attacker can change the command that the program executes: the attacker explicitly controls the command.
- 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, the possibility that an attacker can control the executed command. Command injection 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 that represents a command the application executes.
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 runs a user-controller command.
cmdName := request.FormValue("Command")
c := exec.Command(cmdName)
c.Run()
desc.dataflow.golang.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker may be able to control 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 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.
Example 1: The following code from a system utility uses the system property
The code in
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
The problem here is that the program does not do any validation on the
Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a
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
Some think that in the mobile world, classic vulnerabilities, such as command injection, do not make sense -- why would a user attack him or herself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.
Example 4: The following code reads commands to be executed from an Android intent.
On a rooted device, a malicious application can force a victim application to execute arbitrary commands with super user privileges.
- 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, the possibility that an attacker may be able to control 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 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.
Example 1: 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.
...
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 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 the 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:\\util\\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(). After the shell is invoked, it will allow for the execution of 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 is from a web application that provides an interface through which users 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.
...
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.Some think that in the mobile world, classic vulnerabilities, such as command injection, do not make sense -- why would a user attack him or herself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.
Example 4: The following code reads commands to be executed from an Android intent.
...
String[] cmds = this.getIntent().getStringArrayExtra("commands");
Process p = Runtime.getRuntime().exec("su");
DataOutputStream os = new DataOutputStream(p.getOutputStream());
for (String cmd : cmds) {
os.writeBytes(cmd+"\n");
}
os.writeBytes("exit\n");
os.flush();
...
On a rooted device, a malicious application can force a victim application to execute arbitrary commands with super user privileges.
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.java.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker may be able to control 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 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.
Example 1: The following code from a system utility uses the environment variable
The code in
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
The problem here is that the program does not do any validation on the
Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a
The problem here is that the program does not specify an absolute path for
- 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, the possibility that an attacker may be able to control 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 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.
Example 1: The following code from a system utility uses the environment variable
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.
var cp = require('child_process');
...
var home = process.env('APPHOME');
var cmd = home + INITCMD;
child = cp.exec(cmd, function(error, stdout, stderr){
...
});
...
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. Since 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 to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the
rman utility. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.
var cp = require('child_process');
var http = require('http');
var url = require('url');
function listener(request, response){
var btype = url.parse(request.url, true)['query']['backuptype'];
if (btype !== undefined){
cmd = "c:\\util\\rmanDB.bat" + btype;
cp.exec(cmd, function(error, stdout, stderr){
...
});
}
...
}
...
http.createServer(listener).listen(8080);
The problem here is that the program does not do any validation on the
backuptype parameter read from the user apart from verifying its existence. After the shell is invoked, it may allow for the execution of multiple commands, and due to the nature of the application, it will run 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 is from a web application that provides an interface through which users 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.
...
require('child_process').exec("make", function(error, stdout, stderr){
...
});
...
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 child_process.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.desc.dataflow.javascript.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker may be able to control 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 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.
Example 1: The following code from a system utility uses the system property
The code in
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
The problem here is that the program does not do any validation on the
Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a
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
- 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, the possibility that an attacker may be able to control 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 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.
Example 1: 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.
...
$home = $_ENV['APPHOME'];
$cmd = $home . $INITCMD;
system(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 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 the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.
...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(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(). After the shell is invoked, it will allow for the execution of 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 is from a web application that provides an interface through which users 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.
...
$result = shell_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.desc.dataflow.php.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker may be able to control 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 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.
Example: The following code defines a T-SQL stored procedure that, when called with untrusted data, will execute a system command controlled by an attacker.
- 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, the possibility that an attacker may be able to control 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 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.
Example: The following code defines a T-SQL stored procedure that, when called with untrusted data, will execute a system command controlled by an attacker.
...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS
DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path
exec xp_cmdshell @cmd
GO
...
References
[1] xp_cmdshell
desc.dataflow.sql.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker may be able to control 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 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.
Example 1: The following code from a system utility uses the system property
The code in
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
The problem here is that the program does not do any validation on the
Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a
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
- 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, the possibility that an attacker may be able to control 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 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.
Example 1: 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.
...
home = os.getenv('APPHOME')
cmd = home.join(INITCMD)
os.system(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 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 the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.
...
btype = req.field('backuptype')
cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
os.system(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(). After the shell is invoked, it will allow for the execution of 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 is from a web application that provides an interface through which users 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.
...
result = os.system("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
os.system(). 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.desc.dataflow.python.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker may be able to control 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 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.
Example 1: The following code from a system utility uses the system property
The code in
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
The problem here is that the program does not do any validation on the
Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a
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
- 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, the possibility that an attacker may be able to control 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 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.
Example 1: 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.
...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(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 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 the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.
...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...
The problem here is that the program does not do any validation on the
backuptype parameter read from the user. After the shell is invoked via Kernel.spawn, it will allow for the execution of 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 is from a web application that provides an interface through which users 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.
...
system("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
Kernel.system(). 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.desc.dataflow.ruby.command_injection
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 provides an interface through which users can update their password on the system.
- 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 provides an interface through which users can update their password on the system.
def changePassword(username: String, password: String) = Action { request =>
...
s'echo "${password}" | passwd ${username} --stdin'.!
...
}
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.scala.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment 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 first scenario, the possibility that an attacker may be able to control 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 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.
Example 1: The following code from a system utility uses the system property
The code in
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
The problem here is that the program does not do any validation on the
Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a
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
- 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, the possibility that an attacker may be able to control 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 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.
Example 1: 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.
...
Dim cmd
Dim home
home = Environ$("AppHome")
cmd = home & initCmd
Shell cmd, vbNormalFocus
...
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 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 the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.
...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...
The problem here is that the program does not do any validation on the
backuptype parameter read from the user. After the shell is invoked, it will allow for the execution of 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 is from a web application that provides an interface through which users 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.
...
$result = shell_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.desc.dataflow.vb.command_injection