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...

Xin LI delphij at gmail.com
Sat Dec 24 04:52:54 UTC 2011


On Fri, Dec 23, 2011 at 4:19 PM, Doug Barton <dougb at freebsd.org> wrote:
> On 12/23/2011 10:42, Alexander Kabaev wrote:
>> On Fri, 23 Dec 2011 20:29:59 +0200
>> Kostik Belousov <kostikbel at 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 at 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 at 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 <delphij at delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die


More information about the svn-src-all mailing list