This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]