Date: Fri, 23 Dec 2011 20:22:35 -0800 From: Xin LI <delphij@gmail.com> To: Doug Barton <dougb@freebsd.org> Cc: src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Colin Percival <cperciva@freebsd.org>, Kostik Belousov <kostikbel@gmail.com>, Alexander Kabaev <kabaev@gmail.com> 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: <CAGMYy3t1bQNGFpef0FGmSS0nAOoPnqOy6y5K-JJvLhaOejJ1cA@mail.gmail.com> In-Reply-To: <4EF51AA8.5040702@FreeBSD.org> References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <201112231058.46642.jhb@freebsd.org> <201112231122.34436.jhb@freebsd.org> <20111223120644.75fe944d@kan.dyndns.org> <20111223175143.GJ50300@deviant.kiev.zoral.com.ua> <20111223132034.12192baa@kan.dyndns.org> <20111223182959.GL50300@deviant.kiev.zoral.com.ua> <20111223134225.11ac22fd@kan.dyndns.org> <4EF51AA8.5040702@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 23, 2011 at 4:19 PM, Doug Barton <dougb@freebsd.org> wrote: > On 12/23/2011 10:42, Alexander Kabaev wrote: >> On Fri, 23 Dec 2011 20:29:59 +0200 >> Kostik Belousov <kostikbel@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 <kostikbel@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 <jhb@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: >>>>>>>>> =C2=A0 Fix a problem whereby a corrupt DNS record can cause >>>>>>>>> named to crash. [11:06] >>>>>>>>> =C2=A0 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. =C2=A0I 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, --=20 Xin LI <delphij@delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGMYy3t1bQNGFpef0FGmSS0nAOoPnqOy6y5K-JJvLhaOejJ1cA>