From owner-freebsd-security@FreeBSD.ORG Thu Dec 29 21:21:04 2011 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA146106566C; Thu, 29 Dec 2011 21:21:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 89A5E8FC0A; Thu, 29 Dec 2011 21:21:04 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 0EABE46B09; Thu, 29 Dec 2011 16:21:04 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 95F4FB915; Thu, 29 Dec 2011 16:21:03 -0500 (EST) From: John Baldwin To: d@delphij.net Date: Thu, 29 Dec 2011 16:17:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <201112291435.03493.jhb@freebsd.org> <4EFCCDDF.5080602@delphij.net> In-Reply-To: <4EFCCDDF.5080602@delphij.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112291617.05113.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Dec 2011 16:21:03 -0500 (EST) Cc: freebsd-security@freebsd.org, Doug Barton Subject: Re: svn commit: r228843 - head/contrib/telnet/libtelnet head/crypto/heimdal/appl/telnet/libtelnet head/include head/lib/libc/gen head/lib/libc/iconv head/lib/libc/include head/lib/libc/net head/libexec... X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 21:21:05 -0000 On Thursday, December 29, 2011 3:30:23 pm Xin Li wrote: > On 12/29/11 11:35, John Baldwin wrote: > > On Thursday, December 29, 2011 2:10:37 pm Xin LI wrote: > >> On Thu, Dec 29, 2011 at 11:00 AM, John Baldwin > >> wrote: > >>> On Thursday, December 29, 2011 1:44:01 pm Xin Li wrote: > >>>> On 12/29/11 10:43, John Baldwin wrote: > >>>>> On Thursday, December 29, 2011 1:26:17 pm Xin Li wrote: > >>>>>> On 12/29/11 06:39, John Baldwin wrote: > >>>>>>> Can you give some more details on why ftpd is > >>>>>>> triggering a dlopen inside of the chroot? It would > >>>>>>> appear that that is unrelated to helper programs (since > >>>>>>> setting a flag in libc in ftpd can't possibly affect > >>>>>>> helper programs ability to use dlopen() from within > >>>>>>> libc). > >>>>>> > >>>>>> Sure. That's because nsdispatch(3) would reload > >>>>>> /etc/nsswitch.conf if it notices a change. After > >>>>>> chroot() the file is considered as "chang"ed and thus it > >>>>>> reloads the file as well as designated shared libraries. > >>>>> > >>>>> But ftpd has to be doing some operation that invokes an nss > >>>>> lookup after entering the chroot for that to trigger, > >>>>> correct? > >>>> > >>>> Oh ok, that was the built-in ls(1). > >>> > >>> Were we not able to drop privilege before doing that? I.e. if > >>> you forked a new process that dropped privilege before doing > >>> the ls (similar to if you were to exec /bin/ls as a helper), > >>> would that not have fixed this? > >> > >> No, it won't. This is arbitrary code execution and not just > >> privilege escalation :( > > > > So how is there not still a problem for helper programs? Is ls the > > only way a user can initiate a helper program? Hmm, looks like > > ftpd will only ever invoke ls, and thus only ls_main(), so there's > > lots of dead code (e.g. where ftpd invokes execv() in ftpd_popen() > > is a dead code path). That clears up some confusion on my part as > > I didn't understand why it was ok to execute arbitrary programs > > from ftpd but the built-in ls was special. I still find the symbol > > name incredibly ugly. Another route might have been set an env > > var > > It is ugly. > > > to disable use of dlopen() in libc. That would have worked even if > > ftpd invoked an external program, whereas the built-in ls is now > > key to security and no longer a simple optimization. > > I think it's not an optimization but how ftpd would work in chroot > environment without a partial or full blown FreeBSD inside chroot > setup? Otherwise one will not be able to do 'ls' if user was chroot. Presumably one could do a static ls. Even with the built-in ls we create a dummy passwd/group file for the anonymous chroot by default. I agree a built-in ls is strictly better, however. I would also be fine with removing all notion of execv for helper programs from ftpd and have it only ever use the built-in ls via ftpd_popen(). > Using an environment variable may be not a good idea since it can be > easily overridden, and I think if the program runs something inside > the chroot, the jailed chroot would have more proper setup to avoid > this type of attack? Well, it would not be possible to override it in the immediate process being executed. Right now that case is not handled at all. However, I do think that this mostly falls down to creating "safe" chroot / jail areas rather than the OS being able to defend unsafe areas. -- John Baldwin