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...

[John Baldwin]

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 at 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