Unquoted Search Path or Element
Weakness ID: 428 (Weakness Base)Status: Draft
+ Description

Description Summary

The product uses a search path that contains an unquoted element, in which the element contains whitespace or other separators. This can cause the product to access resources in a parent path.

Extended Description

If a malicious individual has access to the file system, it is possible to elevate privileges by inserting such a file as "C:\Program.exe" to be run by a privileged program making use of WinExec.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

All

Operating Systems

Windows 2000: (Sometimes)

Windows XP: (Sometimes)

Windows Vista: (Sometimes)

Mac OS X: (Rarely)

Platform Notes

This weakness could apply to any OS that supports spaces in filenames, especially any OS that make it easy for a user to insert spaces into filenames or folders, such as Windows. While spaces are technically supported in Unix, the practice is generally avoided. .

+ Demonstrative Examples

Example 1

(Bad Code)
Example Languages: C and C++ 
UINT errCode = WinExec( "C:\\Program Files\\Foo\\Bar", SW_SHOW );
+ Observed Examples
ReferenceDescription
CVE-2005-1185Small handful of others. Program doesn't quote the "C:\Program Files\" path when calling a program to be executed - or any other path with a directory or file whose name contains a space - so attacker can put a malicious program.exe into C:.
CVE-2005-2938CreateProcess() and CreateProcessAsUser() can be misused by applications to allow "program.exe" style attacks in C:
CVE-2000-1128Applies to "Common Files" folder, with a malicious common.exe, instead of "Program Files"/program.exe.
+ Potential Mitigations

Software should quote the input data that can be potentially executed on a system.

Phase: Architecture and Design

Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data to be displayed or stored. Use an "accept known good" validation strategy. Input (specifically, unexpected CRLFs) that is not appropriate should not be processed into HTTP headers.

Do not rely exclusively on blacklist validation to detect malicious input or to encode output. There are too many variants to encode a character; you're likely to miss some variants.

Inputs should be decoded and canonicalized to the application's current internal representation before being validated. Make sure that your application does not decode the same input twice. Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked.

+ Other Notes

Fault: missing quoting

Design Limitation: whitespace allowed in identifiers.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory417Channel and Path Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class668Exposure of Resource to Wrong Sphere
Research Concepts (primary)1000
+ Research Gaps

Under-studied, probably under-reported.

+ Functional Areas
  • Program invocation
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnquoted Search Path or Element
+ Related Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.4)
38Leveraging/Manipulating Configuration File Search Paths
+ Maintenance Notes

This weakness primarily involves the lack of quoting, which is not explicitly stated as a part of CWE-116. CWE-116 also describes output in light of structured messages, but the generation of a filename or search path (as in this weakness) might not be considered a structured message.

An additional complication is the relationship to control spheres. Unlike untrusted search path (CWE-426), which inherently involves control over the definition of a control sphere, this entry concerns a fixed control sphere in which some part of the sphere may be under attacker control. This is not a clean fit under CWE-668 or CWE-610, which suggests that the control sphere model needs enhancement or clarification.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential Mitigations, Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other Notes, Taxonomy Mappings
2009-07-27CWE Content TeamMITREInternal
updated Applicable Platforms, Description, Maintenance Notes, Other Notes, Potential Mitigations, Relationships