Untrusted Search Path| ID: 426 | Date: (C)2012-05-14 (M)2022-10-10 |
| Type: compound element | Status: DRAFT |
| Abstraction Type: Base |
Description
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 PlatformsLanguage Class: Language-independentOperating System Class: OS-independent
Time Of Introduction
- Architecture and Design
- Implementation
Related Attack Patterns
Common Consequences
| Scope | Technical Impact | Notes |
|---|
| IntegrityConfidentialityAvailabilityAccess_Control | Gain privileges / assume
identityExecute unauthorized code or
commands | There is the potential for arbitrary code execution with privileges of
the vulnerable program. |
| Availability | 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. |
| Confidentiality | Read files or
directories | The program could send the output of unauthorized files to the
attacker. |
Detection Methods
| Name | Description | Effectiveness | Notes |
|---|
| 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
| Phase | Strategy | Description | Effectiveness | Notes |
|---|
| 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. | | |
| Implementation | | When invoking other programs, specify those programs using
fully-qualified pathnames. | | |
| 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. | | |
| 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. | | |
| 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. | | |
| 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. | | |
Relationships
| Related CWE | Type | View | Chain |
|---|
| CWE-426 ChildOf CWE-878 | Category | CWE-868 | |
Demonstrative Examples (Details)
- This code prints all of the running processes belonging to the
current user. (Demonstrative Example Id DX-68)
- 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
- 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.
For more examples, refer to CVE relations in the bottom box.
White Box Definitions None
Black Box Definitions None
Taxynomy Mappings
| Taxynomy | Id | Name | Fit |
|---|
| 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 | |
References:
- 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.
- M. Howard D. LeBlanc .Writing Secure Code 1st Edition. Microsoft. Section:'Chapter 8, "Canonical Representation Issues." Page
229.'. Published on 2002.
- 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.
- 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.
