logo

Creation of chroot Jail Without Changing Working Directory

Draft Variant
Structure: Simple
Description

The product uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.

Extended Description

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.
Common Consequences 1
Scope: Confidentiality

Impact: Read Files or Directories
Detection Methods 1
Automated Static AnalysisHigh
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.)
Demonstrative Examples 1
Consider the following source code from a (hypothetical) FTP server:

Code Example:

Bad
C
c
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 does not 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.
References 1
Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors
Katrina Tsipenyuk, Brian Chess, and Gary McGraw
NIST Workshop on Software Security Assurance Tools Techniques and Metrics • NIST
07-11-2005
https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf
ID: REF-6
Likelihood of Exploit

High

Applicable Platforms
Languages:
C : UndeterminedC++ : Undetermined
Modes of Introduction
Implementation
Affected Resources
  1. File or Directory
Related Weaknesses
ChildOf: Improper Following of Specification by Caller (CWE-573)
ChildOf: Incorrect Resource Transfer Between Spheres (CWE-669)
Taxonomy Mapping
  • 7 Pernicious Kingdoms
  • Software Fault Patterns