About 'DLL Search Order Hijacking' vulnerability?
Windows systems use a standard method to look for required DLLs to load into a program. Adversaries may take advantage of the Windows DLL search order and programs that ambiguously specify DLLs to gain privilege escalation and persistence.
Adversaries may perform DLL preloading, also called binary planting attacks, by placing a malicious DLL with the same name as an ambiguously specified DLL in a location that Windows searches before the legitimate DLL. Often this location is the current working directory of the program.
If a search order-vulnerable program is configured to run at a higher privilege level, then the adversary-controlled DLL that is loaded will also be executed at the higher privilege. In this case, the technique could be used for privilege escalation from user to administrator or SYSTEM or from administrator to SYSTEM, depending on the program.
Programs that fall victim to path hijacking may appear to behave normally because malicious DLLs may be configured to also load the legitimate DLLs they were meant to replace.
Mitigation plan
Developers may choose to mitigate DLL search order hijacking (or just DLL hijacking) in installers using one (or both!) of the strategies mentioned below:
- Fixing DLL search order for specific loaded DLLs
- Choosing a secure design pattern [mentioned in this post]
Most of the developers prefer (1) over (2). There are certain issues associated with using just the first approach:
- Developers may forget to fix DLL search paths of certain DLLs
- In future updates, the installer may introduce loading new DLLs which aren't sanitized for search order hijacking
- The installer may be loading some 3rd party component (may be Microsoft's) which in turn is loading a DLL. These components may not be sanitized for this vulnerability and developers have no control over these components
Choosing strategy (2) or a mix of (1) + (2) [which is ideal!] will ensure that our installers are comparatively safe from getting exploited even if there may be inherent vulnerabilities in the code due to the issues mentioned above.
Secure Design Pattern for creating installers
For installers, it is recommended to have an intermediary installer that will download the main installer in a newly created temp directory with a random name. The intermediary installer will only require kernel32.dll which ignores the application directory for searching DLL path. The main installer will then execute from the temp directory. This will mitigate any DLL planting attacks.
List of DLLs that ignores application directory path is mentioned in the following registry entry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs
