CWE-427 Detail

The product uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.

Although this weakness can occur with any type of resource, it is frequently introduced when a product uses a directory search path to find executables or code libraries, but the path contains a directory that can be modified by an attacker, such as "/tmp" or the current working directory.

In Windows-based systems, when the LoadLibrary or LoadLibraryEx function is called with a DLL name that does not contain a fully qualified path, the function follows a search order that includes two path elements that might be uncontrolled:

• the directory from which the program has been loaded
• the current working directory

In some cases, the attack can be conducted remotely, such as when SMB or WebDAV network shares are used.

One or more locations in that path could include the Windows drive root or its subdirectories. This often exists in Linux-based code assuming the controlled nature of the root directory (/) or its subdirectories (/etc, etc), or a code that recursively accesses the parent directory. In Windows, the drive root and some of its subdirectories have weak permissions by default, which makes them uncontrolled.

In some Unix-based systems, a PATH might be created that contains an empty element, e.g. by splicing an empty variable into the PATH. This empty element can be interpreted as equivalent to the current working directory, which might be an untrusted search element.

In software package management frameworks (e.g., npm, RubyGems, or PyPi), the framework may identify dependencies on third-party libraries or other packages, then consult a repository that contains the desired package. The framework may search a public repository before a private repository. This could be exploited by attackers by placing a malicious package in the public repository that has the same name as a package from the private repository. The search path might not be directly under control of the developer relying on the framework, but this search order effectively contains an untrusted element.

Modes Of Introduction

Implementation

Applicable Platforms

Language

Class: Not Language-Specific (Undetermined)

Operating Systems

Class: Not OS-Specific (Undetermined)

Common Consequences

Observed Examples

Potential Mitigations

Phases : Architecture and Design // Implementation
Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428.
Phases : Implementation
When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.
Phases : Implementation
Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths.
Phases : Implementation
Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory. Since this is a denylist approach, it might not be a complete solution.
Phases : Implementation
Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of finding the program using the PATH environment variable, while execl() and execv() require a full path.

Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Effectiveness : High

Vulnerability Mapping Notes

Justification : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comment : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Related Attack Patterns

NotesNotes

Unlike untrusted search path (CWE-426), which inherently involves control over the definition of a control sphere (i.e., modification of a search path), this entry concerns a fixed control sphere in which some part of the sphere may be under attacker control (i.e., the search path cannot be modified by an attacker, but one element of the path can be under attacker control).
This weakness is not a clean fit under CWE-668 or CWE-610, which suggests that the control sphere model might need enhancement or clarification.

References

REF-409

Double clicking on MS Office documents from Windows Explorer may execute arbitrary programs in some cases
Georgi Guninski.
https://seclists.org/bugtraq/2000/Sep/331

REF-410

ACROS Security: Remote Binary Planting in Apple iTunes for Windows (ASPR #2010-08-18-1)
Mitja Kolsek.
https://lists.openwall.net/bugtraq/2010/08/18/4

REF-411

Automatic Detection of Vulnerable Dynamic Component Loadings
Taeho Kwon, Zhendong Su.
https://dl.acm.org/doi/10.1145/1831708.1831722

REF-412

Dynamic-Link Library Search Order
https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order?redirectedfrom=MSDN

REF-413

Dynamic-Link Library Security
https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security

REF-414

An update on the DLL-preloading remote attack vector
https://msrc.microsoft.com/blog/2010/08/an-update-on-the-dll-preloading-remote-attack-vector/

REF-415

Insecure Library Loading Could Allow Remote Code Execution
https://learn.microsoft.com/en-us/security-updates/securityadvisories/2010/2269637#insecure-library-loading-could-allow-remote-code-execution

REF-416

Application DLL Load Hijacking
HD Moore.
https://www.rapid7.com/blog/?p=5325

REF-417

DLL Hijacking: Facts and Fiction
Oliver Lavery.
https://threatpost.com/dll-hijacking-facts-and-fiction-082610/74384/

REF-1168

Microsoft warns enterprises of new 'dependency confusion' attack technique
Catalin Cimpanu.
https://www.zdnet.com/article/microsoft-warns-enterprises-of-new-dependency-confusion-attack-technique/

REF-1169

Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies
Alex Birsan.
https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

REF-1170

3 Ways to Mitigate Risk When Using Private Package Feeds
Microsoft.
https://azure.microsoft.com/mediahandler/files/resourcefiles/3-ways-to-mitigate-risk-using-private-package-feeds/3%20Ways%20to%20Mitigate%20Risk%20When%20Using%20Private%20Package%20Feeds%20-%20v1.0.pdf

REF-1325

exec package - os/exec - Go Packages
https://pkg.go.dev/os/exec

REF-1326

Git LFS Changelog
Brian M. Carlson.
https://github.com/git-lfs/git-lfs/commit/032dca8ee69c193208cd050024c27e82e11aef81

Submission

Modifications