Tag Archives: Untrusted Search Path

CWE-426 – Untrusted Search Path

Read Time:2 Minute, 28 Second

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.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-642
CWE-668
CWE-673
CWE-427
CWE-428

 

Consequences

Integrity, Confidentiality, Availability, Access Control: Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands

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

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

Confidentiality: Read Files or Directories

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

 

Potential Mitigations

Phase: Architecture and Design, Implementation

Description: 

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 CWE-426 and CWE-428.

Phase: Implementation

Description: 

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

Description: 

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

Description: 

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

Description: 

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.

CVE References

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