1035
Strategy = Attack Surface Reduction
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.
Phase: Implementation
Strategy = Attack Surface Reduction
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.
Phase: Implementation
Strategy = Attack Surface Reduction
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.
Phase: 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.
Phase: 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.
Demonstrative Examples
Example 1:
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 extra privileges.
Example Language: Java (Bad)
...
System.Runtime.getRuntime().exec("make");
...
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.
Example 2:
CWE Version 4.14
CWE-427: Uncontrolled Search Path Element
CWE-427: Uncontrolled Search Path Element