CWE-426 Details

The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.

Einführungsmodi

Implementation

Anwendbare Plattformen

Sprache

Class: Not Language-Specific (Undetermined)

Betriebssysteme

Class: Not OS-Specific (Undetermined)

Häufige Konsequenzen

Beobachtete Beispiele

Mögliche Gegenmaßnahmen

Phases : Architecture and Design // Implementation
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.
Phases : 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.
Phases : 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.
Phases : 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.
Phases : 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.

Erkennungsmethoden

Black Box

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Wirksamkeit : High

Manual Analysis

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.

Hinweise zur Schwachstellen-Zuordnung

Begründung : This CWE entry is often confused with another closely-related entry about search paths.
Kommentar : CWE-426 and CWE-427 are often misused because they both mention search paths, although CWE-426 is focused on attacker control of the search path itself, while CWE-427 applies when the attacker cannot modify the search path but can write to one of the locations specified in the search path. Also, this entry is classified in a part of CWE's hierarchy that does not have sufficiently low-level coverage, which might reflect a lack of classification-oriented weakness research in the software security community. Conduct careful root cause analysis to determine the original mistake that led to this weakness. If closer analysis reveals that this weakness is appropriate, then this might be the best available CWE to use for mapping. If no other option is available, then it is acceptable to map to this CWE.

Verwandte Angriffsmuster

Referenzen

REF-18

The CLASP Application Security Process
Secure Software, Inc..
https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf

REF-62

The Art of Software Security Assessment
Mark Dowd, John McDonald, Justin Schuh.

REF-176

Writing Secure Code
Michael Howard, David LeBlanc.

REF-207

Building Secure Software: How to Avoid Security Problems the Right Way
John Viega, Gary McGraw.

REF-7

Writing Secure Code
Michael Howard, David LeBlanc.
https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223

Einreichung

Änderungen