From owner-freebsd-questions Thu Sep 26 13:24:33 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA24179 for questions-outgoing; Thu, 26 Sep 1996 13:24:33 -0700 (PDT) Received: from guava.blueberry.co.uk ([194.70.52.51]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA24016 for ; Thu, 26 Sep 1996 13:24:04 -0700 (PDT) Received: (from nik@localhost) by guava.blueberry.co.uk (8.7.5/8.7.3) id VAA12432 Thu, 26 Sep 1996 21:19:21 +0100 (BST) Date: Thu, 26 Sep 1996 21:19:21 +0100 (BST) Message-Id: <199609262019.VAA12432@guava.blueberry.co.uk> MIME-Version: 1.0 X-Newsreader: knews 0.9.7 References: <3247B219.3869@tiasa.es> <528qs4$srb@jester.nvl.army.mil> In-Reply-To: From: nik@blueberry.co.uk (Nik Clayton) Subject: Re: Is chroot dangerous ?? X-Original-Newsgroups: comp.admin.policy,comp.security.firewalls,comp.security.unix,comp.unix.admin,comp.unix.aix To: questions@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just saw this posted to comp.security.unix (among others). While I don't know the process place to look (nor did I fully follow the code when I got there, not being a Unix internals hacker) but it looks like /src/sys/kern/vfs_syscalls.c (if that is the right place) doesn't have anything like this patch. Is this a problem (albeit a small one) that's been fixed post 2.1.5? N In article , tqbf@enteract.com (Thomas H. Ptacek) writes: > 25 Sep 1996 10:41:03 +0100 andrewg@microlise.co.uk: >>If you are root inside a chroot environment, then you first need to >>tighten up the chroot() call itself, since the standard behaviour of >>chroot() and chdir() allows for an easy escape. > > The problem you're talking about is a bug in BSD. For the benefit of the > class: > > 'root' inside of a chroot()'d jail can easily break out of chroot() by > 1. chroot()'ing again to a directory under the current directory > 2. chdir()'ing to '..' a couple hundred times. > > The problem is that, as stated in the man pages, chroot() does not affect > a process's current directory. When you chroot() and don't immediately > chdir() somewhere under the new root directory, you've overwritten your > process's root directory pointer and have left your current directory > pointer pointing to a directory ABOVE the root directory. > > The "bug" is that this condition causes the name translation checks that > change ".." to "." when they hit the root directory to fail. > > This is an easily fixed problem, and has nothing to do with how secure the > concept of chroot() is (assuming your chroot() is implemented > appropriately). Our fix to the problem was to cause chroot() to > automatically set the current directory to "/" after a chroot() when the > process's root directory pointer is non-null (meaning the process has > already chroot()'d). OpenBSD has a similar fix. Last I checked, FreeBSD > was still vulnerable to this, even though the details of the problem were > posted to freebsd-security. > >>How did you handle chroot() and chdir()? > > if(p->p_fd->fd_rdir != NULL) { > vrele(p->p_fd->fd_rdir); > vrele(p->p_fd->fd_cdir); > > VREF(nd.ni_vp); > > p->p_fd->fd_rdir = p->p_fd->fd_cdir = nd.ni_vp; > } > > -- > ----------------------------------------------------------------------------- > Tom Ptacek at The rdist Organization / exit(main(kfp->kargc, argv, environ)); > ------------------------------------------------[ tqbf@rdist.org ]----------- > "If you're so special, why aren't you dead?" > > > -- --+=[ Blueberry Hill Blueberry New Media ]=+-- --+=[ http://www.blueberry.co.uk/ 1/9 Chelsea Harbour Design Centre, ]=+-- --+=[ WebMaster@blueberry.co.uk London, England, SW10 0XE ]=+-- --+=[ Somedays, I wonder why I even bother chewing through the straps. ]ENTP