SV.DLLPRELOAD.NONABSOLUTE.DLL
Potential DLL-preload hijack vector
When an application loads an external library, it's important for the code to use a fully qualified path. If an insufficiently qualified path is specified, a malicious attacker can gain control of the search path and use it as a vector for remotely executing arbitrary code. This type of threat is known as binary planting or DLL-preloading attacks.
The DLLPRELOAD.NONABSOLUTE.DLL checker flags code instances in which there are missing or NULL pathnames in system file-manipulation function calls LoadLibrary and LoadLibraryEx to .dll files.
Fore more information on DLL-preloading attacks, see Microsoft's Security Advisory 2269637.
Vulnerability and risk
An attacker can use relative pathnames to read, modify, or overwrite critical files, bypassing security mechanisms. Failure to use a fully qualified path can allow your application to load a DLL other than that intended. An exploiter can use this vulnerability to gain user rights, achieve elevated privileges, and even take control of the system.
Mitigation and prevention
To avoid relative path problems:
- Make sure that external libraries are loaded securely, using fully qualified pathnames whenever possible
- Include built-in path canonicalization functions such as realpath() or canonicalize_file_name() in the code
- Store library, include, and utility files in separate directories where they can't be easily accessed
- Make sure error messages don't disclose path information
For more suggestions for mitigation and prevention of DLL-preloading attacks, see Microsoft's Dynamic-Link Library Security article.
Vulnerable code example
HINSTANCE myLoadLibraryX() {
return LoadLibrary("X.dll");
}
Klocwork produces an issue report at line 2 indicating that calling LoadLibrary without a fully qualified path may allow the application to load a DLL from an arbitrary location. Any call to a file-manipulation function that uses a relative or NULL pathname can produce an unpredictable and possibly dangerous response.
Fixed code example
HINSTANCE myLoadLibraryX() {
return LoadLibrary("C:\\myapp\\X.dll");
}
In the fixed code example, a fully qualified path has been provided, eliminating the possibility of malicious access.
Related checkers
External guidance
- CERT FIO02-C: Canonicalize path names originating from tainted sources
- CERT WIN00-C: Be specific when dynamically loading libraries
- OWASP A1:2021 Broken Access Control
- OWASP A4:2021 Insecure Design
- CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
- CWE-23: Relative Path Traversal
- CWE-73: External Control of File Name or Path
- CWE-114: Process Control
- STIG-ID:APP3600 Canonical Representation
- Microsoft's Security Advisory 2269637
- Microsoft's Dynamic-Link Library Security article
Security training
Application security training materials provided by Secure Code Warrior.