[Forgot Password]
Login  Register Subscribe












Paid content will be excluded from the download.

Download | Alert*
view XML

Untrusted Search Path

ID: 426Date: (C)2012-05-14   (M)2017-11-16
Type: compound elementStatus: DRAFT
Abstraction Type: Base


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.

Likelihood of Exploit: High

Applicable Platforms
Language Class: Language-independent
Operating System Class: OS-independent

Time Of Introduction

  • Architecture and Design
  • Implementation

Related Attack Patterns

Common Consequences

ScopeTechnical ImpactNotes
Gain privileges / assume identity
Execute unauthorized code or commands
There is the potential for arbitrary code execution with privileges of the vulnerable program.
DoS: crash / exit / 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.
Read files or directories
The program could send the output of unauthorized files to the attacker.

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

Potential Mitigations

Architecture and Design
 Hard-code your search path to a set of known-safe values, or 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-427 and CWE-428.
 When invoking other programs, specify those programs using fully-qualified pathnames.
 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.
 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 dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
 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.


Related CWETypeViewChain
CWE-426 ChildOf CWE-878 Category CWE-868  

Demonstrative Examples   (Details)

  1. This code prints all of the running processes belonging to the current user. (Demonstrative Example Id DX-68)
  2. 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. (Demonstrative Example Id DX-67)

Observed Examples

  1. CVE-1999-1120 : Application relies on its PATH environment variable to find and execute program.
  2. CVE-2008-1810 : Database application relies on its PATH environment variable to find and execute program.
  3. CVE-2007-2027 : Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages.
  4. CVE-2008-3485 : Untrusted search path using malicious .EXE in Windows environment.
  5. CVE-2008-2613 : setuid program allows compromise using path that finds and loads a malicious library.
  6. 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.

For more examples, refer to CVE relations in the bottom box.

White Box Definitions

Black Box Definitions

Taxynomy Mappings

PLOVER  Untrusted Search Path
CLASP  Relative path library search
CERT C Secure Coding ENV03-C
Sanitize the environment when invoking external programs
CERT C++ Secure Coding ENV03-CPP
Sanitize the environment when invoking external programs


  1. Mark Dowd John McDonald Justin Schuh .The Art of Software Security Assessment 1st Edition. Addison Wesley. Section:'Chapter 10, Process Attributes, page 603'. Published on 2006.
  2. M. Howard D. LeBlanc .Writing Secure Code 1st Edition. Microsoft. Section:'Chapter 8, "Canonical Representation Issues." Page 229.'. Published on 2002.
  3. John Viega Gary McGraw .Building Secure Software: How to Avoid Security Problems the Right Way 1st Edition. Addison-Wesley. Section:'Chapter 12, "Trust Management and Input Validation." Pages 317-320.'. Published on 2002.
  4. M. Howard D. LeBlanc .Writing Secure Code 2nd Edition. Microsoft. Section:'Chapter 11, "Don't Trust the PATH - Use Full Path Names" Page 385'. Published on 2002.

© 2013 SecPod Technologies