Date: Mon, 05 Dec 2011 11:48:55 -0800 From: Xin Li <delphij@delphij.net> To: Mike Tancsa <mike@sentex.net> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, d@delphij.net, Przemyslaw Frasunek <przemyslaw@frasunek.com> Subject: Re: ftpd security issue ? Message-ID: <4EDD2027.9030807@delphij.net> In-Reply-To: <4EDD1F2F.20802@sentex.net> References: <4ED68B4D.4020004@sentex.net> <4ED69B7E.50505@frasunek.com> <4ED6C3C6.5030402@delphij.net> <4ED6D1CD.9080700@sentex.net> <4ED6D577.9010007@delphij.net> <4EDD1F2F.20802@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/11 11:44, Mike Tancsa wrote: > On 11/30/2011 8:16 PM, Xin LI wrote: >> On 11/30/11 17:01, Mike Tancsa wrote: >>> On 11/30/2011 7:01 PM, Xin LI wrote: >>>> >>>>> BTW. This vulnerability affects only configurations, where >>>>> /etc/ftpchroot exists or anonymous user is allowed to >>>>> create files inside etc and lib dirs. >>>> >>>> This doesn't seem to be typical configuration or no? >> >>> I think in shared hosting environments it would be somewhat >>> common. For annon ftp, I dont think the anon user would be able >>> to create / write to a lib directory. >> >>>> >>>> Will the attached patch fix the problem? >>>> >>>> (I think libc should just refuse /etc/nsswitch.conf and >>>> libraries if they are writable by others by the way) >> >>> It does not seem to prevent the issue for me. Using >>> Przemyslaw program's, >> >> Sorry I patched at the wrong place, this one should do. >> >> Note however this is not sufficient to fix the problem, for >> instance one can still upload .so's that run arbitrary code at >> his privilege, which has to be addressed in libc. I need some >> time to play around with libc to really fix this one. > > Forgive the naive question, but is there a way to prevent a process > (in this case proftpd) from loading a .so if the session is in a > chrooted environment ? Or if at the start of the process, is there > a way to force the process to load a lib so that later on, it wont > try and load the "bad" lib ? Currently no (I thought you were in the cc list in my discussion with kib@?). My initial plan was simply rejecting .so's with wrong permissions but in the discussion turns out that would not be sufficient and we have also considered other ways to do it, e.g. have a wrapper where one can disable them completely. I have not a full solution yet as the change would touch quite a lot of things in the base system... - -- 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) iEYEARECAAYFAk7dICcACgkQOfuToMruuMCwmQCcDggWC5xvH1dik8i55KQXVaQq ZtEAn0OCbzspSS2sKfOs1MsDHc9mw2su =pxAJ -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EDD2027.9030807>