CWE-426 Untrusted Search Path

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.

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. Programming languages may have their own paths for locating code, e.g. PERL5LIB in Perl. • 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.

• Integrity, Confidentiality, Availability, Access Control: Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands — There is the potential for arbitrary code execution with privileges of the vulnerable program. If the product uses a search path to locate critical resources such as programs or libraries, then an attacker could modify that search path to point to a malicious program/library, which the targeted product would then execute. • Availability: DoS: Crash, Exit, or Restart — 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. • Confidentiality: Read Files or Directories — The program could access unauthorized data and send the output of unauthorized files to the attacker. • Other: Varies by Context — The problem extends to any type of critical resource that the product trusts. For example, the attacker could modify configuration in unexpected ways.

• [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. • [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. • [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. • [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 it, while execl() and execv() require a full path.

• 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 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 traffic. 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: 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.) • 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 may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

• 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. • CVE-2008-1319: Server allows client to specify the search path, which can be modified to point to a program that the client has uploaded.