Re: [PATCH v9] Add getentropy, getrandom, <sys/random.h> [BZ #17252]

[Zack Weinberg <zackw at panix dot com>]

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