From owner-freebsd-security@FreeBSD.ORG Sun Dec 25 05:14:45 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 968181065673; Sun, 25 Dec 2011 05:14:45 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 05B248FC15; Sun, 25 Dec 2011 05:14:44 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so9043619obb.13 for ; Sat, 24 Dec 2011 21:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OL5oU3XV/gP5p11T6m90tuftfIrLjmuzXVT/Mo8KpMI=; b=rTp/KxEAp2aJSqsX6CxHpPP9nJX4dguH2Mb0PSB5cXnhjhlhPTpBtU6SG4k1B2NuFK 9rktOazXm1Wu9m0u4RZDtVqoTygxkLakCiSb9UFUaOMKHrMQS/ZgQntngTR60S8N2Yfu K4i5cSNYJ1Kg7khmKE1g9IaxP2ecjhKqP2uM0= MIME-Version: 1.0 Received: by 10.182.15.104 with SMTP id w8mr18185788obc.20.1324790084161; Sat, 24 Dec 2011 21:14:44 -0800 (PST) Received: by 10.182.67.163 with HTTP; Sat, 24 Dec 2011 21:14:44 -0800 (PST) In-Reply-To: <4EF6444F.6090708@FreeBSD.org> References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <201112231058.46642.jhb@freebsd.org> <201112231122.34436.jhb@freebsd.org> <20111223120644.75fe944d@kan.dyndns.org> <20111223175143.GJ50300@deviant.kiev.zoral.com.ua> <20111224100509.GA98136@vniz.net> <20111224103948.GA10939@vniz.net> <20111224105045.GA11127@vniz.net> <8E5EE6FA-7BA1-4590-843A-F5C3C0493E5B@FreeBSD.org> <4EF6444F.6090708@FreeBSD.org> Date: Sat, 24 Dec 2011 21:14:44 -0800 Message-ID: From: Xin LI To: Doug Barton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org 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: Sun, 25 Dec 2011 05:14:45 -0000 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. =C2=A0Again, 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. Cheers, --=20 Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die