Date: Thu, 29 Dec 2011 09:39:53 -0500 From: John Baldwin <jhb@freebsd.org> To: Xin LI <delphij@gmail.com> Cc: freebsd-security@freebsd.org, Doug Barton <dougb@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... Message-ID: <201112290939.53665.jhb@freebsd.org> In-Reply-To: <CAGMYy3uzLXMvw40q1hM9dnHGxxh%2BeO_8Y1nbNKsPSB_Aenmm7w@mail.gmail.com> References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <4EF6444F.6090708@FreeBSD.org> <CAGMYy3uzLXMvw40q1hM9dnHGxxh%2BeO_8Y1nbNKsPSB_Aenmm7w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <dougb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112290939.53665.jhb>