fortify scan:Process Control

Abstract:

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. It could result in the program using a malicious library supplied by an attacker.

Explanation:

Process control vulnerabilities take two forms:

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

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

Process control vulnerabilities of this type occur when:

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.

Example: 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 makes use of a library named liberty.dll, which is normally found in a standard system directory.

LoadLibrary("liberty.dll");

The problem is that the program does not specify an absolute path for liberty.dll. If an attacker is able to place a malicious library named liberty.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 liberty.dll will now be run with elevated privileges, possibly giving the attacker complete control of the system.

The type of attack shown in this example is made possible because of 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 the 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.

Recommendations:

An attacker may indirectly control libraries that are used by a program by modifying the environment in which libraries are loaded. The environment should not be trusted and precautions should be taken to prevent an attacker from using some manipulation of the environment to perform an attack. Whenever possible, libraries should be controlled by the application and executed using an absolute path. In cases where the path is not known at compile time, such as for cross-platform applications, an absolute path should be constructed from known values during execution. Because an attacker may indirectly control libraries that are loaded by a program by modifying the environment in which they are executed. The environment should not be trusted and precautions should be taken to prevent an attacker from using some manipulation of the environment to perform an attack. Whenever possible, libraries should be controlled by the application and loaded using an absolute path. In cases where the path is not known at compile time, such as for cross-platform applications, an absolute path should be constructed from known values during execution.

Because Windows APIs impose a specific search order based not only on a series of directories, but also on a list of file extensions that are automatically appended if none is specified, an attacker may be able to inject a malicious library of the specified name with an extension higher in the search order. Therefore, absolute paths should also specify a file extension on Windows systems.

Library names and paths read from configuration files or the environment should be sanity-checked against a set of invariants that define valid values. Other checks can sometimes be performed to detect if these sources may have been tampered with. For example, if a configuration file is world-writable, the program might refuse to run.

In cases where information about the library to be loaded is known in advance, the program may perform checks to verify the identity of the library. If a library should always be owned by a particular user or have a particular set of access permissions assigned to it, these properties can be verified programmatically before the library is loaded.