Chroot Protection and Breaking

Chroot protection and breaking Anton Chuvakin, Ph.D. WRITTEN: 2001-2003 (unknown) DISCLAIMER: Security is a rapidly changing field of human endeavor. Threats we face literally change every day; moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even though I hope that this document will be useful for to my readers, please keep in mind that is was possibly written years ago. Also, keep in mind that some of the URL might have gone 404, please Google around. Chroot command and chroot system call might sound like a good security measure - one command executed and plain old UNIX
cd /
no longer transports you to a root directory of the system. Instead, you are bound to stay in the restricted part of the filesystem, surrounded only by files chosen by a paranoid system administrator. In fact, that is how it should be. Is it possible to break out of chroot solitary confinement? Yes, if certain conditions are met. In this paper we will analyze what chroot is good for and also what chroot is bad for. First, how does it work? When one types '/sbin/chroot directory_name' on the UNIX system command line one sees that the new root is now 'directory_name' (the '/bin/ls /' command produces the listing of files from 'directory_name' presuming that you have an 'ls' command located within your new root). Chroot shell command changes the root directory for a process, goes into this directory and then starts a shell or a user-specified command. Chroot command uses a chroot() system call. The command and the system call have an important difference between them: unlike the shell command, chroot() call does not change your working directory to the one inside chrooted jail. The source of chroot.c (shell command, in Linux part of sh-utils) shows the following sequence of system calls: ----------------- chroot (argv[1]); chdir (
/
); ----------------- As will be seen further, it will allow for easy chroot jail breaking. Chroot is often used as a security measure. If one has ever used an anonymous ftp server, one has used chroot. Ftp server chroots itself into a special directory upon the anonymous ftp login. DNS (Domain Name System) daemon bind is often chrooted as well. People also suggested chrooting telnet/ssh remote shell users into their corresponding home directories, so they can only update their web pages. Web servers can be run chrooted too. Smap secure email wrapper from FWTK firewall tool kit runs chrooted to the mail spool directory. When chroot is implemented, programs running inside cannot access any system resources on the outside. Thus all system libraries, configuration files and even devices files should be recreated within the chroot jail. What daemons can be chrooted? If a daemon has to access files that are not easily collectible in one place, chrooting it will be hard. For example, sendmail needs mail spool (/var/spool/mail), other files in spool (such as mqueue), user's home directories (to check for .forward files) and system configuration files in /etc. There is no place on the filesystem where sendmail can be effectively confined. Of course, some makeshift solution is possible, but it is not clear that it will add to security, but rather cause it to lax. If sendmail functionality is separated into spool daemon and mail transfer program (like done in FWTK smap and smapd), than chrooting is entirely possible. Chrooting shell users is possible if there is a business need to keep them in some particular directory. Suggestions for doing this with ssh2 are provided here: http://www.ssh.com/faq/index.cfm?id=687, and for openssh here: http://hints.linuxfromscratch.org/hints/openssh.txt and: http://archives.neohapsis.com/archives/sf/linux/2001-q4/0197.html However, it might involve copying multiple system libraries, files and other resources such as Linux Pluggable Authentication Modules (PAM) architecture, used by most modern Linux distributions. Anything else such as bind, apache, squid can be chrooted, but sometimes the benefits are unclear, especially for daemons that run as root. This URL (http://www.networkdweebs.com/chroot.html) provides a nice list of daemons that its author chrooted successfully.
What daemon should be chrooted?
is an entirely different question from
What daemons can be chrooted?
Before we answer it, lets analyze how attackers break out of chroot. First, the more software is deployed within chroot environment, the more dangerous it becomes, since it is hard to keep track of programs that can be used by the attacker to elevate permission and escape. Second, the number of ways that root user can break out of chroot is huge. Starting from simple use of a chroot() call with no chdir() [see code below] to esoteric methods as the creation of your own /dev/hda or /dev/kmem devices, injection code into the running kernel (http://www.big.net.au/~silvio/runtime-kernel-kmem-patching.txt), using open directory handles outside chroot or chroot-breaking buffer overflows. While system capabilities can be used to render inoperable many of these methods, new ones will likely be found by smart attackers. --------------- Sample code to break out of chroot: #include ,[object Object]

Chroot Protection and Breaking

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Chroot Protection and Breaking

Similaire à Chroot Protection and Breaking (20)

Plus de Anton Chuvakin

Plus de Anton Chuvakin (20)

Dernier

Dernier (20)

Chroot Protection and Breaking