From owner-freebsd-security@FreeBSD.ORG Thu Dec 29 15:31:01 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 123581065672; Thu, 29 Dec 2011 15:31:01 +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 D3F9B8FC0A; Thu, 29 Dec 2011 15:31:00 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 8D05346B52; Thu, 29 Dec 2011 10:31:00 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E8FFEB96E; Thu, 29 Dec 2011 10:30:59 -0500 (EST) From: John Baldwin To: Xin LI Date: Thu, 29 Dec 2011 09:39:53 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <4EF6444F.6090708@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112290939.53665.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Dec 2011 10:31:00 -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 15:31:01 -0000 On Sunday, December 25, 2011 12:14:44 am Xin LI wrote: > Hi, Doug, > > On Sat, Dec 24, 2011 at 1:29 PM, Doug Barton wrote: > > On 12/24/2011 12:46, Xin LI wrote: > >> Won't work because the binary might be run by privileged but chroot > >> user. Again, this is the first proposal that we have considered. > > > > Now that the cat is out of the bag, and a fix is available, might it not > > make sense to summarize the private discussions about this issue > > somewhere, and brainstorm about a better solution? I'd suggest -hackers, > > or perhaps -security as good public lists to do this on. > > > > A quick writeup along the lines of, "Here are the ideas we considered, > > and here is why we rejected them" would jump-start the discussion, and > > perhaps ease the frustration of the people who are just now looking at > > this and scratching their heads. > > > > I understand why the previous discussion was undertaken privately, but > > there is no need to continue the secrecy any longer. > > Here are the ideas we have came with patches and get dropped for some > reason (not solving all problems, cause incompatibility issue, etc): > > a) Have dynamic linker check permissions (w^x policy) on shared > library when program was setuid; > b) Have nsdispatch(3) check permissions on configuration files; > c) Have a dlopen(3) wrapper that have a flag that allows caller to say > "this is security sensitive and don't load libraries that have > suspicious permissions" > d) Completely disable nsdispatch reload feature; > e) The current version; > f) The current version but with a wrapper around chroot(2) that > disables all libc dlopen(3) calls; > g) The current version with libc_dlopen(3) exposed as a new API as > well and/or have the ugly API exposed in FBSD_1.2 namespace. This is > primarily trivial cleanup changes and both were denied. > > Requirement were: > > - Must not break existing and legitimate use of chroot(2), in other > words no semantics change permitted. > - Must fix the ftpd(8) issue itself since it's already public. > - Must not break anything other than the attack, e.g. require > additional steps other than patching. 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). -- John Baldwin