1033
[REF-7]Michael Howard and David LeBlanc. "Writing Secure Code". 2nd Edition. 2002
December 4. Microsoft Press. < https://www.microsoftpressstore.com/store/writing-securecode-
9780735617223 >.
CWE-427: Uncontrolled Search Path Element
Weakness ID : 427
Structure : Simple
Abstraction : Base
Description
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.
Extended Description
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.
Relationships
The table(s) below shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOr and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition, relationships such
as PeerOf and CanAlsoBe are defined to show similar weaknesses that may want to be explored.
Relevant to the view "Research Concepts" (CWE-1000)
CWE Version 4.14
CWE-427: Uncontrolled Search Path Element
CWE-427: Uncontrolled Search Path Element