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

[Xin LI]

On Thu, Dec 29, 2011 at 11:00 AM, John Baldwin <jhb at freebsd.org> wrote:
> On Thursday, December 29, 2011 1:44:01 pm Xin Li wrote:
>> On 12/29/11 10:43, John Baldwin wrote:
>> > On Thursday, December 29, 2011 1:26:17 pm Xin Li wrote:
>> >> On 12/29/11 06:39, John Baldwin wrote:
>> >>> 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).
>> >>
>> >> Sure.  That's because nsdispatch(3) would reload
>> >> /etc/nsswitch.conf if it notices a change.  After chroot() the
>> >> file is considered as "chang"ed and thus it reloads the file as
>> >> well as designated shared libraries.
>> >
>> > But ftpd has to be doing some operation that invokes an nss lookup
>> > after entering the chroot for that to trigger, correct?
>>
>> Oh ok, that was the built-in ls(1).
>
> Were we not able to drop privilege before doing that?  I.e. if you
> forked a new process that dropped privilege before doing the ls
> (similar to if you were to exec /bin/ls as a helper), would that not
> have fixed this?

No, it won't.  This is arbitrary code execution and not just privilege
escalation :(

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