How to break out of a chroot() jail

This page details how the chroot() system call can be used to provide an additional layer of security when running untrusted programs. It also details how this additional layer of security can be circumvented.

chroot() is a Unix system call that is often used to provide an additional layer of security when untrusted programs are run. The kernel on Unix varients which support chroot() maintain a note of the root directory each process on the system has. Generally this is "/", but the chroot() system call can change this. When chroot() is successfully called, the calling process has its idea of the root directory changed to the directory given as the argument to chroot(). For example after the following line of code, the process would see the directory "/foo/bar" as its root directory.

chdir("/foo/bar");
chroot("/foo/bar");

Important:	When using chroot() in anger you need more than the above code; see below for details.

Note the use of the chdir() call before the chroot() call. This is to ensure that the working directory of the process is within the chroot()ed area before the chroot() call takes place. This is due to most implementations of chroot() not changing the working directory of the process to within the directory the process is now chroot()ed in.

This means that after the chroot() call, an open("/",O_RDONLY) would open the same directory as an open("/foo/bar",O_RDONLY) call before the chroot().

Due to the change in the root directory, the area which a chroot()ed program lives in will require various files and programs for sane operation. For example, the following files are required for the sane operation of the basic shell interpreter sh within a chroot()ed environment.

It should be noted that the more complex and larger a program gets, the more support files it will use. For example, perl requires a very large number of files and directories to work within a chroot()ed environment - 2610 files and 192 directories for a reasonable installation.

Whilst chroot() is reasonably secure, a program can escape from its trap. So long as a program is run with root (ie UID 0) privilages it can be used to break out of a chroot()ed area. For a user to do this, they would need access to:

It should be noted that this document was written with protecting web servers from rogue CGI scripts in mind. Therefore it is not unreasonable to assume that a user has access to a Perl interpreter. It is then a matter for the user to gain root access via security holes on the box running the web server. Whilst this is outside the topic of the document, an attacker could make use of application programs which are setuid-root and have security holes within them. In a well maintained chroot() area such programs should not exist. However, it should be noted that maintaining a chroot()ed environment is a non-trival task, for example system patches which fix such security holes will not know about the copies of the programs within the chroot()ed area. Ensuring that there are no setuid-root executables within the padded cell is going to be a must.

To break out of a chroot()ed area, a program should do the following:

	Create a temporary directory in its current working directory
	Open the current working directory Note: only required if chroot() changes the calling program's working directory.
	Change the root directory of the process to the temporary directory using chroot().
	Use fchdir() with the file descriptor of the opened directory to move the current working directory outside the chroot()ed area. Note: only required if chroot() changes the calling program's working directory.
	Perform chdir("..") calls many times to move the current working directory into the real root directory.
	Change the root directory of the process to the current working directory, the real root directory, using chroot(".")

Once the above has been done, the program can run functions as required. A natural function would be to exec() a command interpreter like sh over the current program. The following C program is an example of the attack outlined above. A Perl version is possible, although it is not shown below.

The following code is known to work under Solaris and Linux. It is likely to work under most (if not all) Unix varients which have the chroot() system call thanks to how it works^[1].

This topic has been discussed on the security column of SunWorld Online which is written by Carole Fennelly; the August 1999 and January 1999 editions cover most of the chroot() topics. In the August 1999 edition Carole goes into how to prevent the attack above from working - the method is a nasty hack involving fsdb (the file system debugger) and a temporary file system^[2]. Basically the method involves fixing the ".." link at the root of the temporary file system so that it points to the root of the file system in much the same way that ".." at the root directory does.

It should be noted that the attack above is quite well known. The fact that it was possible^[3] was alleuded to in "An evening with Berferd"^[4] An exploit^[5] against the wu-ftpd FTP daemon was also posted to the BugTraq mailing list on 1999-03-25. The post containing the exploit is held within the BugTraq archives - see http://www.securityfocus.com/archive/1/12962 for details.

Finally it should be noted that not all version of Unix are vulnerable to this attack. FreeBSD 4.x and above have a better chroot() system call. It can be made to fail if the process has any file descriptors open on a directory. This works by stopping the attack above which essentially works due to a file handle being open on a directory.

Have a look at the FreeBSD 4.x manual page for chroot() for more details. Also have a look at the manual page for jail() which uses chroot() and can limit a process further under FreeBSD.

A very important aspect of writing secure code is the principle of "least privilage". That is, the code should run as the least powerful user which is able to do the task required.

The call to chroot() is normally used to ensure that code run after it can only access files at or below a given directory. Originally, chroot() was used to test systems software in a safe environment. It is now generally used to lock users into an area of the file system so that they can not look at or affect the important parts of the system they are on. For example, the most common use of chroot() is ensuring that when user of an anonymous FTP site can not view important system configuration files^[6]

This normally means that the user will not be running as root. If this is the case the call to chroot() should look something like the following:

chdir("/foo/bar");
chroot("/foo/bar");
setuid(non zero UID);

Where non zero UID is the UID the user should be using. This should be a value other than 0, i.e. not the root user. If this is done there should be no way to gain root privilages unless an attacker uses something within the chroot() jail to gain those privilages.

The seteuid() call should not be used if it can be helped as this does not change the real UID of the process, only its effective UID. It is possible of a process which has a real UID of 0 to do a seteuid(0) to regain root privilages even if its effective UID is not 0 - its the real UID which matters.

There are some cases where it is not easily possible to make use of the setuid() call. In these cases, seteuid() could be looked at. However the developer has to bear in mind that it is a simple hop-skip-seteuid(0) for a process to regain its root privilages and then use the method above to break out of the chroot() jail. The only real reason for making use of the seteuid() call is if the process needs to do something as root on behalf of the user. One example of this is the use of PASV FTP connections as the FTP server will often use ports in the range of 1 to 1024 which requires root privilages.

Such situations can be coded around, however they tend to have their own problems as well.

[1]	The root directory (i.e. /) is stored within each process's entry in the process table. All the chroot() system call does is to change the location of the root directory for that process. Under Solaris the location of the root directory is stored in the user structure as a pointer to a vnode structure. i.e. user.u_rdir is a struct vnode *. The user structure, available from /usr/include/sys/user.h, can be found by referencing the p_user entry in the proc structure which even process is given. See /usr/include/sys/proc.h for details of the proc structure.
[2]	It involves a temporary file system as fsck would complain bitterly if it was run over a file system which had this protection method run over it.
[3]	Which got me thinking in the first place about how you could do the above
[4]	"An evening with Berford in which a Cracker is Lured, Endured and Studied" is a document written by Bill Cheswick which cronicles a crackers actitivies after being lured in a chroot()ed padded cell.
[5]	The realpath() buffer over-run is used in this one
[6]	i.e. /etc/passwd on systems which do not use a shadow password file