CWE-426: Untrusted Search Path

Description:
The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.

Extended Description:
This might allow attackers to execute their own programs, access unauthorized data files, or modify configuration in unexpected ways. If the product 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 product would then execute. The problem extends to any type of critical resource that the product 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.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-642, CWE-668, CWE-673

Consequences:
  - Integrity: Gain Privileges or Assume Identity
  - Availability: DoS: Crash, Exit, or Restart
  - Confidentiality: Read Files or Directories

Detection methods:
  - Black Box: 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 w
  - 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 havin
  - Manual Analysis: 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 m

Mitigations:
  - [Architecture and Design] 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.
  - [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-qualifie
  - [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.
  - [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.

Demonstrative examples:
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.
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.
#define DIR "/restricted/directory" 
                      char cmd[500]; sprintf(cmd, "ls -l %480s", DIR); 
                      /* Raise privileges to those needed for accessing DIR. */ 
                      
                      RaisePrivi

The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.
The code above allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.
... String home = System.getProperty("APPHOME"); String cmd = home + INITCMD; java.lang.Runtime.getRuntime().exec

Real-world examples:
  - CVE-1999-1120: Application relies on its PATH environment variable to find and execute program.
  - CVE-2008-1810: Database application relies on its PATH environment variable to find and execute program.
  - CVE-2007-2027: Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages.
  - CVE-2008-3485: Untrusted search path using malicious .EXE in Windows environment.
  - CVE-2008-2613: setuid program allows compromise using path that finds and loads a malicious library.