SV.DLLPRELOAD.NONABSOLUTE.EXE

Potential DLL-preload process-injection 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.EXE checker flags code instances in which relative pathnames are used in system file-manipulation function calls CreateProcess, WinExec, LoadModule, _exec*, _wexec*, _spawn*, _wspawn*, and ShellExecute to .exe 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. For example, a malicious user can add a new account at the end of a password file to avoid authentication, or read the password file to break into an account on the system. In a worst-case scenario, users can be locked out of the system, software can be prevented from operating, or unauthorized commands or code can be executed.

Failure to use a fully qualified path can allow your application to load an executable file other than that intended. An exploiter can use this vulnerability to inject malicious executable code and run it on the user's machine.

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

1  BOOL createChild() {
2      return CreateProcess("child.exe", NULL, NULL, NULL, FALSE, 0, NULL, NULL, NULL, NULL); 
3  }

Klocwork produces an issue report at line 2 indicating that calling CreateProcess without a fully qualified path may allow the application to load an .exe file from an arbitrary location. Any call to a file-manipulation function that uses a relative path name can produce an unpredictable and possibly dangerous response. Special elements in a path like the parent directory shortcut (..) and filename separators (/) can make the path a vector for remotely executing arbitrary code.

Fixed code example

1  BOOL createChild() {
2      return CreateProcess("C:\\MyApp\\child.exe", NULL, NULL, NULL, FALSE, 0, NULL, NULL, NULL, NULL);  
3  }

In the fixed code example, a fully qualified path has been provided, eliminating the possibility of malicious access.

Related checkers

• SV.DLLPRELOAD.NONABSOLUTE.DLL
• SV.DLLPRELOAD.NONABSOLUTE.EXE
• SV.DLLPRELOAD.SEARCHPATH

External guidance

• 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
• FIO02-C:Canonicalize path names originating from untrusted sources
• STIG-ID:APP3600 Canonical Representation
• 2010 CWE/SANS Top 25 Most Dangerous Programming Errors
• Microsoft's Security Advisory 2269637
• Microsoft's Dynamic-Link Library Security article