On Fri, Dec 23, 2011 at 4:19 PM, Doug Barton <do...@freebsd.org> wrote: > On 12/23/2011 10:42, Alexander Kabaev wrote: >> On Fri, 23 Dec 2011 20:29:59 +0200 >> Kostik Belousov <kostik...@gmail.com> wrote: >> >>> On Fri, Dec 23, 2011 at 01:20:34PM -0500, Alexander Kabaev wrote: >>>> On Fri, 23 Dec 2011 19:51:43 +0200 >>>> Kostik Belousov <kostik...@gmail.com> wrote: >>>> >>>>> On Fri, Dec 23, 2011 at 12:06:44PM -0500, Alexander Kabaev wrote: >>>>>> On Fri, 23 Dec 2011 11:22:34 -0500 >>>>>> John Baldwin <j...@freebsd.org> wrote: >>>>>> >>>>>>> On Friday, December 23, 2011 10:58:46 am John Baldwin wrote: >>>>>>>> On Friday, December 23, 2011 10:00:38 am Colin Percival >>>>>>>> wrote: >>>>>>>>> Author: cperciva >>>>>>>>> Date: Fri Dec 23 15:00:37 2011 >>>>>>>>> New Revision: 228843 >>>>>>>>> URL: http://svn.freebsd.org/changeset/base/228843 >>>>>>>>> >>>>>>>>> Log: >>>>>>>>> Fix a problem whereby a corrupt DNS record can cause >>>>>>>>> named to crash. [11:06] >>>>>>>>> Add an API for alerting internal libc routines to the >>>>>>>>> presence of "unsafe" paths post-chroot, and use it in >>>>>>>>> ftpd. [11:07] >>>>>>>> >>>>>>>> Eh, the whole libc_dlopen() thing looks like a gross hack >>>>>>>> (and who came up with that weird symbol name for a public >>>>>>>> API????). Is it really even needed given the other fix to >>>>>>>> have ftpd drop privilege before execing a helper program? >>>>>>>> I guess the main reason I don't like it is it doesn't do >>>>>>>> anything to address the more general problem. I would have >>>>>>>> expected instead something to restrict dlopen() entirely >>>>>>>> including from other libraries than just libc in certain >>>>>>>> circumstances. >>>>>>> >>>>>>> At the very least if we feel that the libc_dlopen() thing is a >>>>>>> temporary band-aid, we should move the new symbols into the >>>>>>> private namespace so we can remove them once the better fix >>>>>>> is in rather than being required to support them forever. >>>>> libc_dlopen() is not exposed. >>>>> The __FreeBSD_libc_enter_restricted_mode() is, and its name is >>>>> ugly exactly to note the ugly intent. I do not see how the symbol >>>>> can go int FBSDprivate_1.0 when it was supposed to be used by >>>>> third-party applications. >>>>> >>>>> Putting this hack into rtld itself IMO has to wide consequences. >>>>> For libc, we can enumerate the points that stop work after the >>>>> call, but for the generic applications the consequences are >>>>> undefined. >>>>>>> >>>>>>> -- >>>>>>> John Baldwin >>>>>> >>>>>> Pardon for not catching that when I had a chance to influence >>>>>> the outcome, but I would like to voice my support to tucking the >>>>>> ugliness into private version namespace. >>>>>> >>>>>> -- >>>>>> Alexander Kabaev >>>>> >>>> Putting symbol into official namespace implies that we are willing >>>> to provide and maintain it forever, which I do not think was the >>>> intent for the function in question. FBSD_PRIVATE says nothing >>>> about who should and should not link to it, only the level of API >>>> stability one has to expect in the end. If/when we have better >>>> security mechanisms (capsicum?) available to users by default, this >>>> should be ripped out with extreme prejudice. >>> >>> The API is offered as a solution to third-parties. Telling them to use >>> the API that is known to be broken in future is wrong step for the >>> project, IMO. >>> >>> I doubt that proftpd will 'go capsicum'. >> >> Then proftp will have to contend with being known security hazard. >> Spamming every supported branch with the symbol that cries just to >> support programs that chroot into arbitrary environments and trust >> anything at all there is wrong step for the project. Committing to >> support said symbol for all of the eternity is even bigger mistake. > > I agree with those that have concerns about this solution. It seems ugly > and painful, and if the vulnerability is so fundamental to chroot and/or > nsdispatch then it seems that more than ftp would be affected.
That's correct, this affects ALL applications that does chroot into a hostile environment where /etc and /lib can be controlled by unprivileged user, which is in my opinion fundamentally insecure in the first place. Cheers, -- Xin LI <delp...@delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
