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);
}
...
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.liberty.dll
, which is intended to be found in a standard system directory.
LoadLibrary("liberty.dll");
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.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
LoadLibrary()
behaves as follows:SafeDllSearchMode
is 1, the search order is as follows:PATH
environment variable.SafeDllSearchMode
is 0, the search order is as follows: PATH
environment variable.[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