Path Traversal: '...' (Triple Dot)
Weakness ID: 32 (Weakness Variant)Status: Incomplete
+ Description

Description Summary

The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly sanitize '...' (triple dot) sequences that can resolve to a location that is outside of that directory.

Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

The '...' manipulation is useful for bypassing some path traversal protection schemes. On some Windows systems, it is equivalent to "..\.." and might bypass checks that assume only two dots are valid. Insufficient filtering, such as removal of "./" sequences, can ultimately produce valid ".." sequences due to a collapse into unsafe value (CWE-182).

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

All

+ Observed Examples
ReferenceDescription
CVE-2001-0467"\..." in web server
CVE-2001-0615"..." or "...." in chat server
CVE-2001-0963"..." in cd command in FTP server
CVE-2001-1193"..." in cd command in FTP server
CVE-2001-1131"..." in cd command in FTP server
CVE-2001-0480read of arbitrary files and directories using GET or CD with "..." in Windows-based FTP server.
CVE-2002-0288read files using "." and Unicode-encoded "/" or "\" characters in the URL.
CVE-2003-0313Directory listing of web server using "..."
CVE-2005-1658Triple dot
+ Potential Mitigations

Assume all input is malicious. Attackers can insert paths into input vectors and traverse the file system. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. Warning: if you attempt to cleanse your data, then do so that the end result is not in the form that can be dangerous. A sanitizing mechanism can remove characters such as '.' and ';' which may be required for some exploits. An attacker can try to fool the sanitizing mechanism into "cleaning" data into a dangerous form. Suppose the attacker injects a '.' inside a filename (e.g. "sensi.tiveFile") and the sanitizing mechanism removes the character resulting in the valid filename, "sensitiveFile". If the input data are now assumed to be safe, then the file may be compromised. See CWE-182 (Collapse of Data Into Unsafe Value).

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.

Use and specify a strong input/output encoding (such as ISO 8859-1 or UTF 8).

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.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base23Relative Path Traversal
Development Concepts (primary)699
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVER'...' (triple dot)
+ Maintenance Notes

This manipulation-focused entry is currently hiding two distinct weaknesses, so it might need to be split. The manipulation is effective in two different contexts: (1) it is equivalent to "..\.." on Windows, or (2) it can take advantage of insufficient filtering, e.g. if the programmer does a single-pass removal of "./" in a string (collapse of data into unsafe value)

+ 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 Maintenance Notes, Relationships, Taxonomy Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description, Maintenance Notes
2008-11-24CWE Content TeamMITREInternal
updated Observed Examples
2009-07-27CWE Content TeamMITREInternal
updated Potential Mitigations
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Triple Dot - '...'