[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <92a77fed-30ab-ed24-b8dd-a1bac3cb0338@ispras.ru>
Date: Wed, 6 Feb 2019 16:40:42 +0300
From: Alexey Izbyshev <izbyshev@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: dlsym(handle) may search in unrelated libraries
Alexander Monakov noticed a confusing detail in my report: I used
"libc.so.6" in my example despite that musl's "make install" creates
"libc.so" only. To clarify, "libc.so.6" has nothing to do with glibc,
and "libc.so.6" may be replaced with just "libc.so" in my example
without any change in semantics.
Alexey
On 2/6/19 12:02 AM, Alexey Izbyshev wrote:
> Hello!
>
> I've discovered a bug in musl dynamic loader (tested on 1.1.21) which
> is demonstrated by the following simple example:
>
> $ cat bar.c
> int bar = 42;
> $ musl-gcc -fPIC -shared bar.c -o libbar.so
> $ cat foo.c
> extern int bar;
> int *foo = &bar;
> $ musl-gcc -fPIC -shared foo.c -L. -lbar -Wl,-rpath='$ORIGIN' -o
> libfoo.so
> $ cat main.c
> #include <dlfcn.h>
> #include <stdio.h>
>
> int main(void) {
> if (!dlopen("libfoo.so", RTLD_NOW))
> return 1;
> void *h = dlopen("libc.so.6", RTLD_NOW);
> printf("%p\n", dlsym(h, "bar"));
> }
> $ musl-gcc main.c -Wl,-rpath='$ORIGIN' -ldl
> $ ./a.out
> 0x7fd7ebe96020
>
> dlsym(handle) is supposed to search only in the library referred to by
> the handle and in its dependencies. "libc.so.6" doesn't have
> dependencies and doesn't have a definition for "bar", so dlsym(h,
> "bar") should return NULL, but it finds "bar" in libbar.so instead.
>
> The problem occurs because of the following:
> 1) Initially, "deps" in dso structure for libc.so.6 is NULL.
> 2) When dlopen("libc.so.6") is called, "first_load" is true, despite
> that it's not actually the first load (ldso/dynlink.c:1835):
>
> /* First load handling */
> int first_load = !p->deps;
> if (first_load) {
> load_deps(p);
>
> 3) load_deps() then iterates over the dso list starting from
> "libc.so.6", treating all libraries found in DT_NEEDED of each
> processed dso as dependencies of "libc.so.6". However, the dso list
> already contains "libfoo.so" loaded earlier, so "libbar.so" (which is
> needed by "libfoo.so") is treated as a dependency of "libc.so.6". As a
> result, dlsym(h, "bar") succeeds.
>
> It's also notable that "libfoo.so" and "libbar.so" were loaded with
> RTLD_LOCAL, but this bug effectively makes their symbols available in
> such searches regardless of the scope of a library used with dlsym().
>
> ISTM that load_deps(p) was written to work only in real "first load"
> situations, where "p" is initially the last dso in the list, and new
> dsos are only added to the list in the course of recursive loading of
> the dependencies of "p".
>
> Could this be fixed? Thanks!
>
> (Please CC me on replying, I'm not subscribed to the list.)
>
> Alexey
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
