The application searches for critical resources using an externally-supplied search path that can point to resources that are not under the application's direct control.
This might allow attackers to execute their own programs, access unauthorized data files, or modify configuration in unexpected ways. If the application uses a search path to locate critical resources such as programs, then an attacker could modify that search path to point to a malicious program, which the targeted application would then execute. The problem extends to any type of critical resource that the application trusts.
Some of the most common variants of untrusted search path are:
In various UNIX and Linux-based systems, the PATH environment variable may be consulted to locate executable programs, and LD_PRELOAD may be used to locate a separate library.
In various Microsoft-based systems, the PATH environment variable is consulted to locate a DLL, if the DLL is not found in other paths that appear earlier in the search order.
Time of Introduction
Architecture and Design
Technical Impact: Gain privileges / assume
identity; Execute unauthorized code or
There is the potential for arbitrary code execution with privileges of
the vulnerable program.
Technical Impact: DoS: crash / exit /
The program could be redirected to the wrong files, potentially
triggering a crash or hang when the targeted file is too large or does
not have the expected format.
Technical Impact: Read files or
The program could send the output of unauthorized files to the
Likelihood of Exploit
Use monitoring tools that examine the software's process as it
interacts with the operating system and the network. This technique is
useful in cases when source code is unavailable, if the software was not
developed by you, or if you want to verify that the build phase did not
introduce any new weaknesses. Examples include debuggers that directly
attach to the running process; system-call tracing utilities such as
truss (Solaris) and strace (Linux); system activity monitors such as
FileMon, RegMon, Process Monitor, and other Sysinternals utilities
(Windows); and sniffers and protocol analyzers that monitor network
Attach the monitor to the process and look for library functions and
system calls that suggest when a search path is being used. One pattern
is when the program performs multiple accesses of the same file but in
different directories, with repeated failures until the proper filename
is found. Library calls such as getenv() or their equivalent can be
checked to see if any path-related variables are being accessed.
Automated Static Analysis
Use automated static analysis tools that target this type of weakness.
Many modern techniques use data flow analysis to minimize the number of
false positives. This is not a perfect solution, since 100% accuracy and
coverage are not feasible.
Use tools and techniques that require manual (human) analysis, such as
penetration testing, threat modeling, and interactive tools that allow
the tester to record and modify an active session. These may be more
effective than strictly automated techniques. This is especially the
case with weaknesses that are related to design and business
This program is intended to execute a command that lists the
contents of a restricted directory, then performs other actions. Assume that
it runs with setuid privileges in order to bypass the permissions check by
the operating system.
#define DIR "/restricted/directory"
sprintf(cmd, "ls -l %480s", DIR);
/* Raise privileges to those needed for accessing DIR.
This code may look harmless at first, since both the directory and the
command are set to fixed values that the attacker can't control. The
attacker can only see the contents for DIR, which is the intended
program behavior. Finally, the programmer is also careful to limit the
code that executes with raised privileges.
However, because the program does not modify the PATH environment
variable, the following attack would work:
The user sets the PATH to reference a directory under that user's
control, such as "/my/dir/".
The user creates a malicious program called "ls", and puts that
program in /my/dir
The user executes the program.
When system() is executed, the shell consults the PATH to find the
The program finds the malicious program, "/my/dir/ls". It doesn't
find "/bin/ls" because PATH does not contain "/bin/".
The program executes the malicious program with the raised
This code prints all of the running processes belonging to the
//assume getCurrentUser() returns a username that is
guaranteed to be alphanumeric (CWE-78)
$userName = getCurrentUser();
$command = 'ps aux | grep ' . $userName;
This program is also vulnerable to a PATH based attack, as an attacker
may be able to create malicious versions of the ps or grep commands.
While the program does not explicitly raise privileges to run the system
commands, the PHP interpreter may by default be running with higher
privileges than users.
The following code is from a web application that allows users
access to an interface through which they can update their password on the
system. In this environment, user passwords can be managed using the Network
Information System (NIS), which is commonly used on UNIX systems. When
performing NIS updates, part of the process for updating passwords is to run
a make command in the /var/yp directory. Performing NIS updates requires
The problem here is that the program does not specify an absolute path
for make and does not clean its environment prior to executing the call
to Runtime.exec(). If an attacker can modify the $PATH variable to point
to a malicious binary called make and cause the program to be executed
in their environment, then the malicious binary will be loaded instead
of the one intended. Because of the nature of the application, it runs
with the privileges necessary to perform system operations, which means
the attacker's make will now be run with these privileges, possibly
giving the attacker complete control of the system.
Server allows client to specify the search path,
which can be modified to point to a program that the client has
Phases: Architecture and Design; Implementation
Strategy: Identify and Reduce Attack Surface
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.
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.
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.
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.
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 it, while execl()
and execv() require a full path.
[REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, Process Attributes, page 603. 1st Edition. Addison Wesley. 2006.
[REF-8] M. Howard and
D. LeBlanc. "Writing Secure Code". Chapter 8, "Canonical Representation Issues." Page
229.. 1st Edition. Microsoft. 2002.
[REF-9] John Viega and
Gary McGraw. "Building Secure Software: How to Avoid Security Problems the
Right Way". Chapter 12, "Trust Management and Input Validation." Pages
317-320.. 1st Edition. Addison-Wesley. 2002.
[REF-11] M. Howard and
D. LeBlanc. "Writing Secure Code". Chapter 11, "Don't Trust the PATH - Use Full Path Names" Page
385. 2nd Edition. Microsoft. 2002.