From owner-freebsd-security@FreeBSD.ORG Thu Dec 29 20:03:29 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 222CC106566C; Thu, 29 Dec 2011 20:03:29 +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 E92848FC17; Thu, 29 Dec 2011 20:03:28 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 8CBB246B2E; Thu, 29 Dec 2011 15:03:28 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 241D2B91E; Thu, 29 Dec 2011 15:03:28 -0500 (EST) From: John Baldwin To: Xin LI Date: Thu, 29 Dec 2011 14:35:03 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <201112291400.41075.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112291435.03493.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Dec 2011 15:03:28 -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 20:03:29 -0000 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 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. -- John Baldwin