Untrusted Search Path
Compound Element ID: 426 (Compound Element Base: Composite)Status: Draft
+ Description

Description Summary

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.

Extended Description

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

+ Alternate Terms
Untrusted Path
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

Operating Systems

All

+ Common Consequences
ScopeEffect
Authorization
Integrity

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

Availability

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

The program could send the output of unauthorized files to the attacker.

+ Likelihood of Exploit

High

+ Demonstrative Examples

Example 1

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.

(Bad Code)
Example Language: C 
#define DIR "/restricted/directory"

char cmd[500];
sprintf(cmd, "ls -l %480s", DIR);
/* Raise privileges to those needed for accessing DIR. */
RaisePrivileges(...);
system(cmd);
DropPrivileges(...);
...

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:

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

The user 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 malicious program, "/my/dir/ls". It doesn't find "/bin/ls" because PATH does not contain "/bin/".

The program executes the malicious program with the raised privileges.

+ Observed Examples
ReferenceDescription
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.
+ Potential Mitigations

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

Phase: Implementation

When invoking other programs, specify those programs using fully-qualified pathnames.

Phase: Implementation

Sanitize your environment 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.

Phase: Testing

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.

Phase: Testing

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.

Phase: Testing

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.

Phase: Testing

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.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
RequiresWeakness ClassWeakness Class216Containment Errors (Container Errors)
Research Concepts1000
RequiresCategoryCategory275Permission Issues
Research Concepts1000
RequiresWeakness BaseWeakness Base471Modification of Assumed-Immutable Data (MAID)
Research Concepts1000
ChildOfCategoryCategory417Channel and Path Errors
Development Concepts (primary)699
ChildOfCategoryCategory634Weaknesses that Affect System Processes
Resource-specific Weaknesses (primary)631
ChildOfWeakness ClassWeakness Class642External Control of Critical State Data
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class673External Influence of Sphere Definition
Research Concepts1000
ChildOfCategoryCategory744CERT C Secure Coding Section 10 - Environment (ENV)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory7522009 Top 25 - Risky Resource Management
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory8082010 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
CanAlsoBeWeakness BaseWeakness Base98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion')
Research Concepts1000
+ Research Gaps

Search path issues on Windows are under-studied and possibly under-reported.

+ Affected Resources
  • System Process
+ Functional Areas
  • Program invocation
  • Code libraries
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUntrusted Search Path
CLASPRelative path library search
CERT C Secure CodingENV03-CSanitize the environment when invoking external programs
+ Related Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.4)
38Leveraging/Manipulating Configuration File Search Paths
+ References
Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, Process Attributes, page 603. 1st Edition. Addison Wesley. 2006.
M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 8, "Canonical Representation Issues." Page 229.. 1st Edition. Microsoft. 2002.
John Viega and Gary McGraw. "Building Secure Software". Chapter 12, "Trust Management and Input Validation." Pages 317-320.. 1st Edition. Addison-Wesley. 2002.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 11, "Don't Trust the PATH - Use Full Path Names" Page 385. 2nd Edition. Microsoft. 2002.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common Consequences, Relationships, Taxonomy Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy Mappings
2009-01-12CWE Content TeamMITREInternal
updated Applicable Platforms, Common Consequences, Demonstrative Examples, Description, Observed Examples, Potential Mitigations, Relationships, Time of Introduction
2009-03-10CWE Content TeamMITREInternal
updated Demonstrative Examples, Potential Mitigations
2009-12-28CWE Content TeamMITREInternal
updated References
Back to top