[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <b400e2a8e98e3731964e0afa171185b6@ispras.ru>
Date: Wed, 06 Feb 2019 00:02:39 +0300
From: Alexey Izbyshev <izbyshev@...ras.ru>
To: musl@...ts.openwall.com
Subject: dlsym(handle) may search in unrelated libraries
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.
