Difference between revisions of "Directory Restriction Error"

From OWASP
Jump to: navigation, search
(Examples)
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{Template:Stub}}
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 +
{{Template:Fortify}}
 +
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 +
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
 
==Description==
 
==Description==
  
Improper use of the chroot() system call may allow attackers to access files that are outside the new root directory therefore breaks the intended access control policy.  
+
Improper use of the chroot() system call may allow attackers to escape a chroot jail.
  
==Related Threats==
+
The application fails to enforce the intended restricted directory access policy. By using relative paths or other path traversal attack mechanisms, an attacker can access unauthorized files outside the restricted directory.
  
Attackers try to access unauthorized files, such as password files or configuration files.
+
== Examples ==
  
==Related Attacks==
+
Improper use of the chroot() system call may allow attackers to access files that are outside the new root directory, and therefore breaks the intended access control policy.
  
[[Path Traversal Attacks]]
+
The chroot() system call allows a process to change its perception of the root directory of the file system. After properly invoking chroot(), a process cannot access any files outside the directory tree defined by the new root directory. Such an environment is called a chroot jail, and is commonly used to prevent the possibility that a processes could be subverted and used to access unauthorized files. For instance, many FTP servers run in chroot jails to prevent an attacker who discovers a new vulnerability in the server from being able to download the password file or other sensitive files on the system.
  
==Related Countermeasures==
+
Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.
  
[[Input Validation]]
+
Consider the following source code from a (hypothetical) FTP server:
[[Access Control]]
+
  
{{Template:Stub}}
+
  chroot("/var/ftproot");
 +
  ...
 +
  fgets(filename, sizeof(filename), network);
 +
  localfile = fopen(filename, "r");
 +
  while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
 +
    fwrite(buf, 1, sizeof(buf), network);
 +
  }
 +
  fclose(localfile);
 +
 
 +
This code is responsible for reading a filename from the network, opening the corresponding file on the local machine, and sending the contents over the network. This code could be used to implement the FTP GET command. The FTP server calls chroot() in its initialization routines in an attempt to prevent access to files outside of /var/ftproot. But because the server fails to change the current working directory by calling chdir("/"), an attacker could request the file "../../../../../etc/passwd" and obtain a copy of the system password file.
 +
 
 +
==Risk Factors==
 +
 
 +
TBD
 +
 
 +
==Examples==
 +
 
 +
TBD
 +
 
 +
==Related [[Attacks]]==
 +
* [[Path Traversal Attacks]]
 +
* Attackers try to access unauthorized files, such as password files or configuration files.
 +
 
 +
 
 +
==Related [[Vulnerabilities]]==
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 
 +
 
 +
==Related [[Controls]]==
 +
* [[Input Validation]]
 +
* [[Access Control]]
 +
 
 +
 
 +
==Related [[Technical Impacts]]==
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
TBD
 +
 
 +
[[Category:FIXME|add links
 +
 
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 
 +
Availability Vulnerability
 +
 
 +
Authorization Vulnerability
 +
 
 +
Authentication Vulnerability
 +
 
 +
Concurrency Vulnerability
 +
 
 +
Configuration Vulnerability
 +
 
 +
Cryptographic Vulnerability
 +
 
 +
Encoding Vulnerability
 +
 
 +
Error Handling Vulnerability
 +
 
 +
Input Validation Vulnerability
 +
 
 +
Logging and Auditing Vulnerability
 +
 
 +
Session Management Vulnerability]]
 +
 
 +
__NOTOC__
 +
 
 +
 
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:C]]
 +
[[Category:Implementation]]
 +
[[Category:Code Snippet]]
 +
[[Category:Use of Dangerous API]]
 +
[[Category:API Abuse]]
 +
[[Category:Vulnerability]]

Latest revision as of 13:08, 21 February 2009

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.


This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


This article includes content generously donated to OWASP by Fortify.JPG.

Last revision (mm/dd/yy): 02/21/2009

Vulnerabilities Table of Contents

Description

Improper use of the chroot() system call may allow attackers to escape a chroot jail.

The application fails to enforce the intended restricted directory access policy. By using relative paths or other path traversal attack mechanisms, an attacker can access unauthorized files outside the restricted directory.

Examples

Improper use of the chroot() system call may allow attackers to access files that are outside the new root directory, and therefore breaks the intended access control policy.

The chroot() system call allows a process to change its perception of the root directory of the file system. After properly invoking chroot(), a process cannot access any files outside the directory tree defined by the new root directory. Such an environment is called a chroot jail, and is commonly used to prevent the possibility that a processes could be subverted and used to access unauthorized files. For instance, many FTP servers run in chroot jails to prevent an attacker who discovers a new vulnerability in the server from being able to download the password file or other sensitive files on the system.

Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.

Consider the following source code from a (hypothetical) FTP server:

 chroot("/var/ftproot");
 ...
 fgets(filename, sizeof(filename), network);
 localfile = fopen(filename, "r");
 while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
   fwrite(buf, 1, sizeof(buf), network);
 }
 fclose(localfile);

This code is responsible for reading a filename from the network, opening the corresponding file on the local machine, and sending the contents over the network. This code could be used to implement the FTP GET command. The FTP server calls chroot() in its initialization routines in an attempt to prevent access to files outside of /var/ftproot. But because the server fails to change the current working directory by calling chdir("/"), an attacker could request the file "../../../../../etc/passwd" and obtain a copy of the system password file.

Risk Factors

TBD

Examples

TBD

Related Attacks

  • Path Traversal Attacks
  • Attackers try to access unauthorized files, such as password files or configuration files.


Related Vulnerabilities


Related Controls


Related Technical Impacts


References

TBD