From owner-freebsd-security  Fri Nov  1 20:01:19 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id UAA17302
          for security-outgoing; Fri, 1 Nov 1996 20:01:19 -0800 (PST)
Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA17294
          for <freebsd-security@freebsd.org>; Fri, 1 Nov 1996 20:01:16 -0800 (PST)
Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id UAA07806; Fri, 1 Nov 1996 20:01:03 -0800 (PST)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199611020401.UAA07806@salsa.gv.ssi1.com>
Date: Fri, 1 Nov 1996 20:01:03 -0800
In-Reply-To: Marc Slemko <marcs@znep.com>
       "Re: chroot() security" (Nov  1,  6:29pm)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: Marc Slemko <marcs@znep.com>, Dev Chanchani <dev@trifecta.com>
Subject: Re: chroot() security
Cc: freebsd-security@freebsd.org
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Nov 1,  6:29pm, Marc Slemko wrote:
} Subject: Re: chroot() security
} On Fri, 1 Nov 1996, Dev Chanchani wrote:

} > Basically, how can someone get out of a chroot()'ed environment is they 
} > get root?
} 
} Many, many ways.

} They can do whatever they want; it may take some effort, but not that
} much.  Simply getting root does not automatically give access to files
} outside the chrooted environment, but it is easy enough to get once you
} have root.  For example, from inside the chrooted environment create
} /dev/sd0a or whatever the root partition is and then you have full access
} to the raw device.  It isn't as easy as just mounting it, since it is
} already mounted once, but it is quite easy to do a few minor edits to get
} root outside the chrooted environment.  Things like /dev/mem and /dev/kmem
} give you access to all the memory on the system.  The user can attach a
} debugger to a process running outside the chrooted environment, then
} modify it to give them access.  The list goes on and on. 

You can add various checks to the kernel to keep chroot()ed processes
from doing a lot of these things, but there is one deadly exploit that
someone posted to this list back in September.  By the clever use of
chroot() and chdir(), it is possible for a root process to waltz out
of a chroot()ed environment.  I don't know of a clean way of plugging
that hole.

BTW, thanks for mentioning ptrace().  I hadn't thought of that one.

			---  Truck