Process Control

Transferring program control to an untrusted program or a transaction, 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 name of the program or the code of the transaction being invoked: the attacker explicitly controls what the program name or transaction code is.

- An attacker can change the environment in which the program or the transaction is invoked: the attacker implicitly controls a communication area made available to the invoked program or the transaction.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the program or the code of the transaction that is invoked. 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 program name or a transaction code that is invoked.



3. By executing code from the invoked program or the transaction, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code excerpt from a privileged system utility reads a value from an HTTP request to determine the code of the transaction to call.

...
tid = request->get_form_field( 'tid' ).

CALL TRANSACTION tid USING bdcdata  MODE 'N'
                         MESSAGES INTO messtab.
...

This code excerpt allows an attacker to call any transaction and potentially execute arbitrary code with the elevated privilege of the application. Because the program does not validate the value read from the HTTP request, if an attacker can control this value, then they can fool the application into running malicious code and take control of the system.

Loading libraries or executables 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 name of the library or executable that the program loads: the attacker explicitly controls what the name of the library or executable is.

- An attacker can change the environment in which the library or executable loads: the attacker implicitly controls what the library or executable name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. 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 library or an executable that is loaded by the application.



3. By executing code from the library or executable, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged system utility uses the application configuration property APPHOME and then loads a native library based on a relative path from the specified directory.

  ...
  string lib = ConfigurationManager.AppSettings["APPHOME"];
  Environment.ExitCode = AppDomain.CurrentDomain.ExecuteAssembly(lib);
  ...

This code allows an attacker to load a library or an executable and potentially execute arbitrary code with the elevated privilege of the application by modifying the application configuration property APPHOME to point to a different path containing a malicious version of LIBNAME. Because the program does not validate the value read from the environment, if 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.

Loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious code on behalf of an attacker.

Process control vulnerabilities take two forms:

- An attacker can change the library that the program executes: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as part of a string representing a library name that is loaded by the application.

3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged application uses a registry entry to determine the directory in which it is installed and loads a library file based on a relative path from the specified directory.

	...
	RegQueryValueEx(hkey, "APPHOME",
                      0, 0, (BYTE*)home, &size);
	char* lib=(char*)malloc(strlen(home)+strlen(INITLIB));
	if (lib) {
		strcpy(lib,home);
		strcat(lib,INITCMD);
		LoadLibrary(lib);
	}
	...

The code in this example allows an attacker to load an arbitrary library, from which code will be executed with the elevated privilege of the application, by modifying a registry key to specify a different path containing a malicious version of INITLIB. Because the program does not validate the value read from the environment, if an attacker can control the value of APPHOME, they can fool the application into running malicious code.

Example 2: The following code is from a web-based administration utility that allows users access to an interface through which they can update their profile on the system. The utility uses a library named liberty.dll, which is intended to be found in a standard system directory.

LoadLibrary("liberty.dll");

However, the program does not specify an absolute path for liberty.dll. If an attacker places a malicious library named liberty.dll higher in the search order than the intended file and has a way to execute the program in their environment rather than the web server's environment, then the application will load the malicious library instead of the trusted one. Because this type of application runs with elevated privileges, the contents of the attacker's liberty.dll is now be run with elevated privileges, potentially giving them complete control of the system.

This type of attack is possible due to the search order used by LoadLibrary() when an absolute path is not specified. If the current directory is searched before system directories, as was the case up until the most recent versions of Windows, then this type of attack becomes trivial if the attacker may execute the program locally. The search order is operating system version dependent, and is controlled on newer operating systems by the value of this registry key:

HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode

This key is not defined on Windows 2000/NT and Windows Me/98/95 systems.

On systems where the key does exist, LoadLibrary() behaves as follows:
If SafeDllSearchMode is 1, the search order is as follows:
(Default setting for Windows XP-SP1 and later, as well as Windows Server 2003.)
1. The directory from which the application was loaded.
2. The system directory.
3. The 16-bit system directory, if it exists.
4. The Windows directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable.
If SafeDllSearchMode is 0, the search order is as follows:
1. The directory from which the application was loaded.
2. The current directory.
3. The system directory.
4. The 16-bit system directory, if it exists.
5. The Windows directory.
6. The directories that are listed in the PATH environment variable.

Transferring program control to an untrusted application program 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 name of the program being invoked: the attacker explicitly controls what the name of the application program is.

- An attacker can change the environment in which the program is invoked: the attacker implicitly controls a communication area made available to the invoked program.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker might control the name of the program that is invoked. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as part of, or the entire string representing a program that is invoked or determines some control over the environment in which the program is invoked.



3. By executing code from the invoked program, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged system utility reads a value from the terminal to determine the name of the program to transfer control to.

...
ACCEPT PROGNAME.
EXEC CICS
  LINK PROGRAM(PROGNAME)
  COMMAREA(COMA)
  LENGTH(LENA)
  DATALENGTH(LENI)
  SYSID('CONX')
END-EXEC.
...

This code allows an attacker to transfer control to a program and potentially execute arbitrary code with the elevated privilege of the application. Because the program does not validate the value read from the terminal, if an attacker can control this value, then they can fool the application into running malicious code and take control of the system.

Loading libraries 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 name of the library that the program loads: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. 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 library that is loaded by the application.



3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code uses a currently undocumented "feature" of Express to dynamically load a library file. Node.js will then continue to search through its regular library load path for a file or directory containing this library[1].

var express = require('express');
var app = express();

app.get('/', function(req, res, next) {
  res.render('tutorial/' + req.params.page);
});

In Express, the page passed to Response.render() will load a library of the extension when previously unknown. This is usually fine for input such as "foo.pug", as this will mean loading the pug library, a well known templating engine. However, if an attacker can control the page and thus the extension, then they can choose to load any library within the Node.js module loading paths. Since the program does not validate the information received from the URL parameter, the attacker may fool the application into running malicious code and take control of the system.

Loading libraries 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 name of the library that the program loads: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. 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 library that is loaded by the application.



3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged system utility uses the system property APPHOME to determine the directory in which it is installed and then loads a native library based on a relative path from the specified directory.

	...
	$home = getenv("APPHOME");
	$lib = $home + $LIBNAME;
	dl($lib);
	...

This code allows an attacker to load a library and potentially execute arbitrary code with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of LIBNAME. 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 uses dl() to load code from a library named sockets.dll, which can be loaded from various places depending on your installation and configuration.

	...
	dl("sockets");
	...

The problem here is that dl() accepts a library name, not a path, for the library to be loaded.

If an attacker is able to place a malicious copy of sockets.dll higher in the search order than file the application intends to load, then the application will load the malicious copy instead of the intended file. Because of the nature of the application, it runs with elevated privileges, which means the contents of the attacker's sockets.dll will now be run with elevated privileges, possibly giving them complete control of the system.

Loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker. Within Ruby there are commonly places where both Process Control and Command Injection attacks can occur.

Within Ruby, Process Control can commonly occur when a command is being executed, which enables two different attacks:

1. Process Control
Process Control vulnerabilities take two forms:

- An attacker can change the name of the library that the program loads: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the second scenario, the possibility that an attacker may be able to control the environment in such a way that the program loads a malicious version of the named library.

1. An attacker provides a malicious library to an application.

2. The application loads the malicious library because it fails to specify an absolute path or verify the file being loaded.

3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Note that Process Control can occur on Windows platforms when running an external program as the shell used to run the commands is chosen via the environment variables RUBYSHELL or COMSPEC. If an attacker is able to modify either of these environment variables within the current environment, it means that the program pointed by these environment variables will be run with the permission or the running Ruby program.

2. Command Injection
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 1: The following code runs Kernel.system() to run an executable called program.exe, which is normally found within a standard system directory.

...
system("program.exe")
...

The problem here is twofold:
1. On Windows platforms, Kernel.system() executes something via a shell. If an attacker can manipulate environment variables RUBYSHELL or COMSPEC, they may be able to point to a malicious executable which will be called with the command given to Kernel.system(). Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's program.exe will now be run with these privileges, possibly giving them complete control of the system.
2. On all platforms in this scenario, the problem is that the program does not specify an absolute path 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 program.exe and then execute the application in their environment, 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 program.exe will now be run with these privileges, possibly giving them complete control of the system.