From owner-freebsd-security@FreeBSD.ORG Thu Dec 29 20:30:24 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 8623B106564A; Thu, 29 Dec 2011 20:30:24 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 65D988FC1F; Thu, 29 Dec 2011 20:30:24 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 2D6EC11241; Thu, 29 Dec 2011 12:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1325190624; bh=DFmS/rtpjg8mUXYmfW9z9ihsegqhMcQcHhAYCHshmww=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lVktTMawKn9kGOiKTpeJdRDMBIHaDX6VC4MmxOoS5UXMMA9yX4eVBby4qmkDle/tj rwUVBfTVVf7i2HInyCRmV2lYWUdjPX2YRJU0jSIyWATvICmmu3EQqT58pK7y+U0Ojo bNg3QD6iAzuHMeLO1gnvoS6Aim/+zb1/ZR+K4JXk= Message-ID: <4EFCCDDF.5080602@delphij.net> Date: Thu, 29 Dec 2011 12:30:23 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: John Baldwin References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <201112291400.41075.jhb@freebsd.org> <201112291435.03493.jhb@freebsd.org> In-Reply-To: <201112291435.03493.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, Doug Barton , d@delphij.net 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 Reply-To: d@delphij.net 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:30:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. 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? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk78zd8ACgkQOfuToMruuMBIBgCfapRMEUnaC+g7EYScfUyeQxpk QgAAnRkTnU0fcgCbbfbOJ+94MiOhN5bP =43gY -----END PGP SIGNATURE-----