CWE-426: Untrusted Search Path | |
| | Untrusted Search Path |
Definition in a New Window 
|
| 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 Time of Introduction
- Architecture and Design
- Implementation
Common Consequences | Scope | Effect |
|---|
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 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) 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 | Reference | Description |
|---|
| 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. |
Potential Mitigations | Phase | Description |
|---|
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 | 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. |
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. |
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 Research Gaps
|
Search path issues on Windows are under-studied and possibly
under-reported.
|
Affected Resources Functional Areas
- Program invocation
- Code libraries
Taxonomy Mappings | Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
|---|
| PLOVER | | | Untrusted Search Path |
| CLASP | | | Relative path library search |
| CERT C Secure Coding | ENV03-C | | Sanitize the environment when invoking external
programs |
Content History | Submissions |
|---|
| Submission Date | Submitter | Organization | Source |
|---|
| PLOVER | | Externally Mined | | | Modifications |
|---|
| Modification Date | Modifier | Organization | Source |
|---|
| 2008-07-01 | Eric Dalci | Cigital | External | | updated Time of Introduction | | 2008-09-08 | CWE Content Team | MITRE | Internal | | updated Common Consequences, Relationships,
Taxonomy Mappings | | 2008-11-24 | CWE Content Team | MITRE | Internal | | updated Relationships,
Taxonomy Mappings | | 2009-01-12 | CWE Content Team | MITRE | Internal | | updated Applicable Platforms, Common Consequences,
Demonstrative Examples, Description, Observed Examples,
Potential Mitigations, Relationships,
Time of Introduction | | 2009-03-10 | CWE Content Team | MITRE | Internal | | updated Demonstrative Examples,
Potential Mitigations |
|
