[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 Feb 2019 17:02:48 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Alexey Izbyshev <izbyshev@...ras.ru>
Subject: Re: dlsym(handle) may search in unrelated libraries
On Wed, Feb 06, 2019 at 12:02:39AM +0300, 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
>
In case you were wondering, your typo here doesn't change anything,
since "libc.so.6" has the prefix "libc.", which is recogized as reserved
in load_library(), and makes dlopen() return a handle to the libc.
Thankfully the patch is simple: Explicitly make ldso and vdso have no
deps. I was tempted to put this into kernel_mapped_dso(), but then I
remembered that the app is also a kernel mapped dso, and it usually does
have deps that need processing. At least, in nontrivial cases.
The attached patch should tide you over.
>
> Alexey
Ciao,
Markus
View attachment "0006-Make-libc-and-vdso-explicitly-have-no-deps.patch" of type "text/x-diff" (1445 bytes)
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.
