ABSTRACT

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

EXPLANATION

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 can 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.

REFERENCES

[1] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A1 Unvalidated Input

[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A4 Insecure Direct Object Reference

[3] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A4 Insecure Direct Object References

[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3570 CAT I

[5] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 114

[6] Dynamic-Link Library Functions Microsoft

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.4

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.1

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.8

[10] Standards Mapping - FIPS200 - (FISMA) SI

[11] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press