CWE-426 不可信的搜索路径

Untrusted Search Path

结构: Simple

Abstraction: Base

状态: Stable

被利用可能性: High

基本描述

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.

扩展描述

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.

Some of the most common variants of untrusted search path are:

相关缺陷

• cwe_Nature: ChildOf cwe_CWE_ID: 642 cwe_View_ID: 1000 cwe_Ordinal: Primary

• cwe_Nature: ChildOf cwe_CWE_ID: 668 cwe_View_ID: 1003 cwe_Ordinal: Primary

• cwe_Nature: ChildOf cwe_CWE_ID: 673 cwe_View_ID: 1000

• cwe_Nature: PeerOf cwe_CWE_ID: 427 cwe_View_ID: 1000

• cwe_Nature: PeerOf cwe_CWE_ID: 428 cwe_View_ID: 1000

适用平台

Language: {'cwe_Class': 'Language-Independent', 'cwe_Prevalence': 'Undetermined'}

Operating_System: {'cwe_Class': 'OS-Independent', 'cwe_Prevalence': 'Undetermined'}

常见的影响

检测方法

DM-11 Black Box

Automated Static Analysis

Manual Analysis

可能的缓解方案

['Architecture and Design', 'Implementation']

策略: Attack Surface Reduction

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.

Implementation

策略:

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.

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.

示例代码

例

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 C

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:

attack

• The user sets the PATH to reference a directory under the attacker's control, such as "/my/dir/".
• The attacker 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 attacker's malicious program, "/my/dir/ls". It doesn't find "/bin/ls" because PATH does not contain "/bin/".
• The program executes the attacker's malicious program with the raised privileges.

例

This code prints all of the running processes belonging to the current user.

bad PHP

This program is also vulnerable to a PATH based attack, as an attacker may be able to create malicious versions of the ps or grep commands. While the program does not explicitly raise privileges to run the system commands, the PHP interpreter may by default be running with higher privileges than users.

例

The following code is from a web application that allows users access to an interface through which they can update their password on the system. In this environment, user passwords can be managed using the Network Information System (NIS), which is commonly used on UNIX systems. When performing NIS updates, part of the process for updating passwords is to run a make command in the /var/yp directory. Performing NIS updates requires extra privileges.

bad Java

The problem here is that the program does not specify an absolute path for make and does not clean its environment prior to executing the call to Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.

分析过的案例

Notes

分类映射

相关攻击模式

• CAPEC-38

引用

• REF-62 The Art of Software Security Assessment

• REF-176 Writing Secure Code

• REF-207 Building Secure Software: How to Avoid Security Problems the Right Way

• REF-7 Writing Secure Code