Description
The software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: High
Related Weaknesses
Consequences
Integrity, Confidentiality, Availability: Execute Unauthorized Code or Commands
The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.
Integrity: Modify Files or Directories
The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.
Confidentiality: Read Files or Directories
The attacker may be able read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.
Availability: DoS: Crash, Exit, or Restart
The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the software from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the software.
Potential Mitigations
Phase: Implementation
Description:
Phase: Architecture and Design
Description:
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Phase: Implementation
Description:
Phase: Architecture and Design
Description:
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Phase: Operation
Effectiveness: Moderate
Description:
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.
An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.
Phase: Architecture and Design, Operation
Description:
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Phase: Architecture and Design
Description:
Phase: Architecture and Design, Operation
Effectiveness: Limited
Description:
The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.
Phase: Architecture and Design, Operation
Description:
Phase: Implementation
Description:
Phase: Operation, Implementation
Description:
When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
CVE References
- CVE-2010-0467
- Newsletter module allows reading arbitrary files using “../” sequences.
- CVE-2009-4194
- FTP server allows deletion of arbitrary files using “..” in the DELE command.
- CVE-2009-4053
- FTP server allows creation of arbitrary directories using “..” in the MKD command.
- CVE-2009-0244
- FTP service for a Bluetooth device allows listing of directories, and creation or reading of files using “..” sequences.
- CVE-2009-4013
- Software package maintenance program allows overwriting arbitrary files using “../” sequences.
- CVE-2009-4449
- Bulletin board allows attackers to determine the existence of files using the avatar.
- CVE-2009-4581
- PHP program allows arbitrary code execution using “..” in filenames that are fed to the include() function.
- CVE-2010-0012
- Overwrite of files using a .. in a Torrent file.
- CVE-2010-0013
- Chat program allows overwriting files using a custom smiley request.
- CVE-2008-5748
- Chain: external control of values for user’s desired language and theme enables path traversal.
- CVE-2009-1936
- Chain: library file sends a redirect if it is directly requested but continues to execute, allowing remote file inclusion and path traversal.