Date: Thu, 29 Dec 2011 12:30:23 -0800 From: Xin Li <delphij@delphij.net> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-security@freebsd.org, Doug Barton <dougb@freebsd.org>, d@delphij.net 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: <4EFCCDDF.5080602@delphij.net> In-Reply-To: <201112291435.03493.jhb@freebsd.org> References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <201112291400.41075.jhb@freebsd.org> <CAGMYy3t89jcmU6AP4Bsa%2Bv%2BVs%2BK7qm_SaqwA5u==wKrzaqTWBQ@mail.gmail.com> <201112291435.03493.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EFCCDDF.5080602>