- CWE-22: Path Traversal
- CWE-78: OS Command Injection
- CWE-79: Cross-Site Scripting
- CWE-89: SQL Injection
- CWE-90: LDAP Injection
- CWE-91: XML Injection
- CWE-94: Code Injection
- CWE-98: PHP File Inclusion
- CWE-113: HTTP Response Splitting
- CWE-119: Buffer Errors
- CWE-130: Improper Handling of Length Parameter Inconsistency
- CWE-193: Off-by-one Error
- CWE-200: Information Exposure
- CWE-211: Information Exposure Through Externally-Generated Error Message
- CWE-236: Improper Handling of Undefined Parameters
- CWE-276: Incorrect Default Permissions
- CWE-284: Improper Access Control
- CWE-287: Improper Authentication
- CWE-345: Insufficient Verification of Data Authenticity
- CWE-352: Cross-Site Request Forgery
- CWE-384: Session Fixation
- CWE-427: Uncontrolled Search Path Element
- CWE-434: Unrestricted Upload of File with Dangerous Type
- CWE-476: NULL Pointer Dereference
- CWE-601: Open Redirect
- CWE-613: Insufficient Session Expiration
- CWE-618: Exposed Unsafe ActiveX Method
- CWE-671: Lack of Administrator Control over Security
- CWE-822: Untrusted Pointer Dereference
- CWE-835: Infinite Loop
CWE is a trademark of the MITRE Corporation.
Uncontrolled Search Path Element [CWE-427]
This weakness occurs during insufficient validation of path when loading an external library.
Created: September 11, 2012
Latest Update: August 6, 2015
Table of Content
- Potential impact
- Attack patterns
- Affected software
- Exploitation Examples
- Severity and CVSS Scoring
- Latest Related Security Advisories
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
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:
- 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:
- The directory from which the application loaded.
- The system directory. Use the GetSystemDirectory function to get the path of this directory.
- The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
- The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
- The current directory.
- 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
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.
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.
- CWE-427: Uncontrolled Search Path Element [cwe.mitre.org]
- Dynamic-Link Library Search Order [msdn.microsoft.com]
- Microsoft Security Advisory (2269637): Insecure Library Loading Could Allow Remote Code Execution [technet.microsoft.com]
9. Latest HTB Security Advisories with CWE-427
Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to High-Tech Bridge is given.↑ Back to Top