Re: svn commit: r228843 - head/contrib/telnet/libtelnet

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/29/11 11:35, John Baldwin wrote:
> On Thursday, December 29, 2011 2:10:37 pm Xin LI wrote:
>> On Thu, Dec 29, 2011 at 11:00 AM, John Baldwin <jhb@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 :(
> 
> So how is there not still a problem for helper programs?  Is ls the
> only way a user can initiate a helper program?  Hmm, looks like
> ftpd will only ever invoke ls, and thus only ls_main(), so there's
> lots of dead code (e.g. where ftpd invokes execv() in ftpd_popen()
> is a dead code path).  That clears up some confusion on my part as
> I didn't understand why it was ok to execute arbitrary programs
> from ftpd but the built-in ls was special.  I still find the symbol
> name incredibly ugly.  Another route might have been set an env
> var

It is ugly.

> to disable use of dlopen() in libc.  That would have worked even if
> ftpd invoked an external program, whereas the built-in ls is now
> key to security and no longer a simple optimization.

I think it's not an optimization but how ftpd would work in chroot
environment without a partial or full blown FreeBSD inside chroot
setup?  Otherwise one will not be able to do 'ls' if user was chroot.

Using an environment variable may be not a good idea since it can be
easily overridden, and I think if the program runs something inside
the chroot, the jailed chroot would have more proper setup to avoid
this type of attack?

Cheers,
- -- 
Xin LI <delphij@delphij.net>	https://www.delphij.net/
FreeBSD - The Power to Serve!		Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk78zd8ACgkQOfuToMruuMBIBgCfapRMEUnaC+g7EYScfUyeQxpk
QgAAnRkTnU0fcgCbbfbOJ+94MiOhN5bP
=43gY
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"