Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190206160248.GB5469@voyager>
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.