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]
On 12/06/2016 11:42 AM, Joseph Myers wrote:
> 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.
On the assumption that this _is_ the issue, I am going to write a script
that scans the Debian archive for existing binaries containing
definitions (exported or not) of getentropy and/or getrandom, and will
report what it tells me -- this will probably take a couple days to
cycle all the way through.
zw