Date: Thu, 26 Sep 1996 21:19:21 +0100 (BST) From: nik@blueberry.co.uk (Nik Clayton) To: questions@freebsd.org Subject: Re: Is chroot dangerous ?? Message-ID: <199609262019.VAA12432@guava.blueberry.co.uk> In-Reply-To: <slrn54jem0.okf.tqbf@enteract.com> References: <3247B219.3869@tiasa.es> <528qs4$srb@jester.nvl.army.mil> <ufzq2fkk40.fsf@zen.microlise.co.uk> <slrn54jem0.okf.tqbf@enteract.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <slrn54jem0.okf.tqbf@enteract.com>,
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609262019.VAA12432>