Uncontrolled Search Path Element [CWE-427]

Uncontrolled Search Path Element weakness occurs during insufficient validation of path when loading an external library.

Created: September 11, 2012
Latest Update: December 28, 2020

Table of Content

1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Exploitation Examples
6. Severity and CVSS Scoring
7. Mitigations
8. References
9. Latest Related Security Advisories

Want to have an in-depth understanding of all modern aspects of
Uncontrolled Search Path Element [CWE-427]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

This weakness occurs when application uses fixed or controlled search path to find resources but one or more locations of the path are under control of malicious user.

On UNIX-based systems this weakness could be exploited via the PATH environment variable that contains an empty element. This empty element can be interpreted as equivalent to the current working directory, which might be an untrusted search path.

On Windows-based systems external libraries are loaded via the LoadLibrary or LoadLibraryEx calls. When DLL name does not contain a fully qualified name or is missing on the system the following search conditions apply:

• If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
• If the DLL is on the list of known DLLs for the version of Windows on which the application is running, the system uses its copy of the known DLL (and the known DLL's dependent DLLs, if any) instead of searching for the DLL. For a list of known DLLs on the current system, see the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.
• If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.

If an attacker gains control over one of the locations that is searched by the system, he can place a malicious library with the corresponding name into this directory and the aforementioned library will be loaded by the application. When loading libraries, Windows applications use predefined search locations as is described:

1. The directory from which the application loaded.
2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

This order is influenced by the
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode
registry value and is set by default starting with Windows XP SP2.

2. Potential impact

Insecure library loading is usually exploitable locally. Nevertheless, the application might use external locations in some cases, such as through SMB or WebDAV network shares. A malicious user can load specially crafted library and execute arbitrary code or commands on the target system with privileges of the vulnerable application.

3. Attack patterns

There are following CAPEC patterns for this weakness:

• CAPEC-38: Leveraging/Manipulating Configuration File Search Paths
• CAPEC-471: DLL Search Order Hijacking

This weakness is not described as an attack technique in WASC Threat Classification database.

4. Affected software

Software that uses external libraries is potentially vulnerable to this weakness.

5. Exploitation Examples

For an exploitation example please refer to our HTB23108 (Privilege Escalation Vulnerability in Microsoft Windows) Security Advisory.

6. Severity and CVSS Scoring

Uncontrolled search path element is usually a locally exploitable vulnerability. But in some cases it is possible to load library from a remote location, for example when a client application is used to open files from a network share and the latter is considered the current working directory. In case of locally exploitable vulnerability the maximum potential impact is privilege escalation and it should be scored as:
7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C) - High severity.

When application is used to open files on remote network shares this weakness becomes remotely exploitable and should be scored as:
9.3 (AV:N/AC:M/Au:N/C:C/I:C/A:C) - Critical severity.

AC:M means that some user interaction is needed, e.g. to open a file or visit a specially crafted webpage.

We use CVSSv2 scoring system in our HTB Security Advisories to calculate the risk of the discovered vulnerabilities. Not all of the vulnerabilities are scored in strict accordance to FIRST recommendations. Our CVSSv2 scores are based on our long internal experience in software auditing and penetration testing, taking into consideration a lot of practical nuances and details. Therefore, sometimes they may differ from those ones that are recommended by FIRST.

7. Mitigations

To avoid exploitation of this weakness developers should use full path when using an external library and should not rely on default search order of DLL files.

When developing application for Windows systems use Microsoft recommendations to limit the attack surface.

8. References

1. CWE-427: Uncontrolled Search Path Element [cwe.mitre.org]
2. Dynamic-Link Library Search Order [msdn.microsoft.com]
3. Microsoft Security Advisory (2269637): Insecure Library Loading Could Allow Remote Code Execution [technet.microsoft.com]

9. Uncontrolled Search Path Element Vulnerabilities, Exploits and Examples

• HTB23108: Privilege Escalation Vulnerability in Microsoft Windows

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.