From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23090 invoked by alias); 6 Dec 2016 16:42:22 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 23074 invoked by uid 89); 6 Dec 2016 16:42:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=Hx-languages-length:1822, risk X-HELO: relay1.mentorg.com Date: Tue, 06 Dec 2016 16:42:00 -0000 From: Joseph Myers To: Zack Weinberg CC: Florian Weimer , Torvald Riegel , GNU C Library Subject: Re: [PATCH v9] Add getentropy, getrandom, [BZ #17252] In-Reply-To: <90908be7-c7db-46f2-a635-27dc5604e47f@panix.com> Message-ID: References: <5b8e5866-d071-9e2c-54e7-2ccf857a2fd8@redhat.com> <97f4db91-49d9-83fa-9f67-6cc718629160@redhat.com> <1480697250.14990.52.camel@redhat.com> <680d0bed-b164-b809-d672-e0278fe08d7e@redhat.com> <90908be7-c7db-46f2-a635-27dc5604e47f@panix.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2016-12/txt/msg00189.txt.bz2 On Tue, 6 Dec 2016, Zack Weinberg wrote: > I still don't really understand what problems you are trying to solve by > mangling names, I still think that ad-hoc addition of mangled names with > forcible redirection in the headers is unlikely to be the *correct* fix > to whatever the problems actually are, and most importantly of all, I > still don't understand why you are convinced *these particular symbols* > need "interposition protection". You said As I understand it, the issue is: a program (or a badly behaved shared library) defines its own getentropy function (without a configure check, or with one that doesn't detect glibc's function). When linked with new glibc, it gets a dynamic symbol export for getentropy. It uses a shared library which has a working configure check for getentropy, and when that shared library is linked with new glibc it has an undefined reference to getentropy. When the newly linked program is run with the newly built glibc, the program's definition of getentropy is used by the shared library, but has semantics different from expected, resulting in a security problem with the library in that combination. Now, until we're sure of the right way to address such issues in general in glibc I suspect distribution-wide checks (that programs don't export symbols that override libc symbols used by shared libraries used, directly or indirectly, by those programs, other than a few common cases such as malloc - and that shared libraries don't interpose libc symbols, similarly) might be a better way to reduce the risk of such issues. But because of dlopen it's hard to know what symbol exports from a program might end up being relevant to shared objects it uses. -- Joseph S. Myers joseph@codesourcery.com