Skip to end of metadata
Go to start of metadata

The LoadLibrary() or LoadLibraryEx() function calls [MSDN] allow you to dynamically load a library at runtime and use a specific algorithm to locate the library within the file system [MSDN]. It is possible for an attacker to place a file on the DLL search path such that your application inadvertently loads and executes arbitrary source code.

Noncompliant Code Example

#include <Windows.h>
 
void func(void) {
  HMODULE hMod = LoadLibrary(TEXT("MyLibrary.dll"));
  if (hMod != NULL) {
    typedef void (__cdecl func_type)(void);
    func_type *fn = (func_type *)GetProcAddress(hMod, "MyFunction");
    if (fn != NULL)
      fn();
  }
}

If an attacker were to place a malicious DLL named MyLibrary.dll higher on the search path than where the library resides, she could trigger arbitrary code to execute either via the DllMain() entrypoint (which is called automatically by the system loader) or by providing an implementation for MyFunction(), either of which would run within the security context of your application. If your application runs with elevated privileges (such as a service application), an escalation of privileges could result.

Compliant Solution

By refusing to load a library unless it is located precisely where expected, you reduce the chance of executing arbitrary code when dynamically loading libraries. This compliant solution uses LoadLibraryEx() to ensure that only the application and System32 directories are searched (eliminating other search paths such as the current directory or PATH environment variable):

#include <Windows.h>
 
void func(void) {
  HMODULE hMod = LoadLibraryEx(TEXT("MyLibrary.dll"), NULL,
                               LOAD_LIBRARY_SEARCH_APPLICATION_DIR |
                               LOAD_LIBRARY_SEARCH_SYSTEM32);
  if (hMod != NULL) {
    typedef void (__cdecl func_type)(void);
    func_type *fn = (func_type *)GetProcAddress(hMod, "MyFunction");
    if (fn != NULL)
      fn();
  }
}

Risk Assessment

Depending on the version of Windows the application is run on, failure to properly specify the library can lead to arbitrary code execution.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

WIN00-C

High

Unlikely

Low

P9

L2

Automated Detection

Tool

Version

Checker

Description

CodeSonar
5.1p0

BADFUNC.PATH.AFXLOADLIBRARY
BADFUNC.PATH.COLOADLIBRARY
BADFUNC.PATH.LOADLIBRARY

Use of AfxLoadLibrary
Use of CoLoadLibrary
Use of LoadLibrary

Klocwork
2018
SV.DLLPRELOAD.NONABSOLUTE.DLL
SV.DLLPRELOAD.NONABSOLUTE.EXE
SV.DLLPRELOAD.SEARCHPATH

Parasoft C/C++test
10.4.2

CERT_C-WIN00-a

Use care to ensure that LoadLibrary() will load the correct library
Polyspace Bug Finder

R2018a

Library loaded from externally controlled path

Load of library from a relative path can be controlled by an external actor

Using a library argument from an externally controlled path

Library loaded with relative path is vulnerable to malicious attacks

Related Guidelines



Bibliography





2 Comments

  1. Just a semantics comment here. I am not sure if "eliminate" is the best choice of wording for the compliant solution.

    That phrasing seems to imply that all chances of arbitrary code execution are dealt with by specifying library locations. It seems like more of a partial mitigation to me; considering that the problems mentioned from the non-compliant solution are still present, just in a more limited fashion.

    1. Yes, perhaps eliminate is too strong of a term here.  This rule really needs a corollary that explains users need to secure their installation directory properly in order to truly eliminate the issue.  But that's extraneous to the contents of the guidelines, so it doesn't really fit anywhere.