This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v9] Add getentropy, getrandom, <sys/random.h> [BZ #17252]
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Torvald Riegel <triegel at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 6 Dec 2016 16:42:01 +0000
- Subject: Re: [PATCH v9] Add getentropy, getrandom, <sys/random.h> [BZ #17252]
- Authentication-results: sourceware.org; auth=none
- 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>
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