freebsd security - Dec 2011 - 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...

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.

Cheers,
-- 
Xin LI <delphij@delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die

On Sat, Dec 24, 2011 at 09:14:44PM -0800, Xin LI wrote:
>  - Must not break existing and legitimate use of chroot(2), in other
> words no semantics change permitted.
Later POSIX drops chroot() completely, so we can feel free of bound of 
the strong legitimacy. 

We already have many counterexamples (mainly related to issetugid()). 
F.e. we disable user locale files - disable functionality. IMHO 
stopping thinking the way that chroot() is fully equivalent to the 
root hierarchy will be good starting point here.

-- 
http://ache.vniz.net/

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