logo

Untrusted Search Path

Stable Base
Structure: Simple
Description

This vulnerability occurs when an application relies on an external search path, provided by a user or environment, to find and load critical resources like executables or libraries. Because the application does not fully control this path, an attacker can manipulate it to point to malicious files.

Extended Description

An untrusted search path allows attackers to hijack the application's resource loading process. By manipulating environment variables like PATH or LD_PRELOAD on Linux, or the DLL search order on Windows, an attacker can trick the application into running their own malicious code, accessing sensitive data, or altering configuration. This happens because the application trusts the search path mechanism without properly validating the final location or integrity of the resources it loads. The core risk is the unauthorized elevation of control. Instead of exploiting a code flaw, the attacker subverts the trusted process of finding dependencies. To prevent this, developers must harden resource loading by using absolute paths, sanitizing environment variables, and explicitly defining safe search directories within the application's control, rather than relying on external system state.
Common Consequences 3
Scope: IntegrityConfidentialityAvailabilityAccess Control

Impact: Gain Privileges or Assume IdentityExecute Unauthorized Code or Commands

There is the potential for arbitrary code execution with privileges of the vulnerable program.

Scope: Availability

Impact: 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.

Scope: Confidentiality

Impact: Read Files or Directories

The program could send the output of unauthorized files to the attacker.
Detection Methods 3
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 AnalysisHigh
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.
Potential Mitigations 5
Phase: Architecture and DesignImplementation

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 Untrusted Search Path and Unquoted Search Path or Element.
Phase: 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.
Phase: 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.
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.
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 it, while execl() and execv() require a full path.
Demonstrative Examples 4

ID : DX-67

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.

Code Example:

Bad
C
c

/* Raise privileges to those needed for accessing DIR. /

c
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:

Code Example:

Attack

  • The user sets the PATH to reference a directory under the attacker's control, such as "/my/dir/".

    • The attacker 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 ls program

    • The program finds the attacker's malicious program, "/my/dir/ls". It doesn't find "/bin/ls" because PATH does not contain "/bin/".

    • The program executes the attacker's malicious program with the raised privileges.

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.

Code Example:

Bad
Java
java
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.

ID : DX-68

This code prints all of the running processes belonging to the current user.

Code Example:

Bad
PHP


//assume getCurrentUser() returns a username that is guaranteed to be alphanumeric (avoiding CWE-78)*
$userName = getCurrentUser();
$command = 'ps aux | grep ' . $userName;
system($command);
If invoked by an unauthorized web user, it is providing a web page of potentially sensitive information on the underlying system, such as command-line arguments (Exposure of Sensitive System Information to an Unauthorized Control Sphere). This program is also potentially vulnerable to a PATH based attack (Untrusted Search Path), 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.
ID : DX-29
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.
Code Example:
Bad
Java
java
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.
  
Observed Examples 6
CVE-1999-1120Application relies on its PATH environment variable to find and execute program.
CVE-2008-1810Database application relies on its PATH environment variable to find and execute program.
CVE-2007-2027Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages.
CVE-2008-3485Untrusted search path using malicious .EXE in Windows environment.
CVE-2008-2613setuid program allows compromise using path that finds and loads a malicious library.
CVE-2008-1319Server allows client to specify the search path, which can be modified to point to a program that the client has uploaded.
  
References 5
The CLASP Application Security Process
Secure Software, Inc.
2005
https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf(2024-11-17)
ID: REF-18
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
Writing Secure Code
Michael Howard and David LeBlanc
Microsoft Press
13-11-2001
ID: REF-176
Building Secure Software: How to Avoid Security Problems the Right Way
John Viega and Gary McGraw
Addison-Wesley
2002
ID: REF-207
Writing Secure Code
Michael Howard and David LeBlanc
Microsoft Press
04-12-2002
https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223
ID: REF-7
 
  
  
 
 
Likelihood of Exploit 
 
 
 
 High 
 
 
  
 
 
Applicable Platforms 
 
 
 
 
 
Languages:
 
 
 Not Language-Specific : Undetermined 
  
  
 
 
 
  
 
 
Modes of Introduction 
 
 
 
 
 
  Implementation  
 
 
 
  
Related Attack Patterns 
  
Alternate Terms 
Untrusted Path
  
 
 
Functional Areas 
 
 
 
     
  1. Program Invocation
  2. Code Libraries
    3.  
 
 
  
 
 
Affected Resources 
 
 
 
     
  1. System Process
    2.  
 
 
  
 
 
Related Weaknesses 
 
 
 
 
  ChildOf:
 External Control of Critical State Data (CWE-642) 
  ChildOf:
 Exposure of Resource to Wrong Sphere (CWE-668) 
  ChildOf:
 External Influence of Sphere Definition (CWE-673) 
  PeerOf:
 Uncontrolled Search Path Element (CWE-427) 
  PeerOf:
 Unquoted Search Path or Element (CWE-428) 
 
 
 
 
Taxonomy Mapping 
  • PLOVER
  • CLASP
  • CERT C Secure Coding