Debian Bug report logs - #33505
glibc dlerror() on dlopen() fails with long (22 char!) filename

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: David Luyer <luyer@ucs.uwa.edu.au>

To: submit@bugs.debian.org

Subject: glibc dlerror() on dlopen() fails with long (22 char!) filename

Date: Wed, 17 Feb 1999 20:22:45 +0800

Package: libc6
Version: 2.0.7.19981211-5
Severity: critical

Justification of severity: I don't know if anything else is getting 
overwritten or what is happening when dlerror() is returning junk.  It
could easily be overflowing an internal buffer, and hence further
investigation is necessary to deduce if this could introduce a serious
security problem into any security sensitive packages which dlopen()
a user library.  Note that dlopen()ing a user library should be OK to
do in code running as root, as long as the code changes user-id before
executing code out of said library, and there could be SUID programs out
there which call dlopen() as root.  Hence this potentially introduces
a security hole, if any code is written using this belief, and should be
critical until investigated (if found not to be the result of a buffer
overflow, then it is just an "important" bug, since it can make
well-written programs misbehave in a way they don't report sensible
errors on failure).

There appears to be a major bug in dlerror() or dlopen(); when I pass 
dlopen() an invalid object (eg, an empty file) with a filename longer than
around 22 characters, I get the first 21 or so characters of the filename
followed by a random character out of dlerror().  The error message and the
rest of the filename are nowhere to be seen.

Verifying filename length was the problem was done by trying to open a
zero-length dll (ie, to get an error) ./blah.so, then changing it to
././././././././././././././././././blah.so, which truncated badly
and did not report an error.

David.

Message #10 received at 33505@bugs.debian.org (full text, mbox, reply):

From: Zack Weinberg <zack@rabi.columbia.edu>

To: David Luyer <luyer@ucs.uwa.edu.au>, 33505@bugs.debian.org

Subject: Re: Bug#33505: glibc dlerror() on dlopen() fails with long (22 char!) filename

Date: Wed, 17 Feb 1999 10:39:50 -0500

On Wed, 17 Feb 1999 20:22:45 +0800, David Luyer wrote:
>
>There appears to be a major bug in dlerror() or dlopen(); when I pass 
>dlopen() an invalid object (eg, an empty file) with a filename longer than
>around 22 characters, I get the first 21 or so characters of the filename
>followed by a random character out of dlerror().  The error message and the
>rest of the filename are nowhere to be seen.

The bug is not present in libc 2.1.  The dynamic linker was completely
rewritten, so I can't find an obvious fix to backport.

I'm a bit suspicious of this bug, 21 chars is absurdly short for a
pathname buffer.  Could you post some sample code please?

zw

Message #15 received at 33505@bugs.debian.org (full text, mbox, reply):

From: Daniel Jacobowitz <dan@debian.org>

To: David Luyer <luyer@ucs.uwa.edu.au>, 33505@bugs.debian.org

Subject: Re: Bug#33505: glibc dlerror() on dlopen() fails with long (22 char!) filename

Date: Wed, 17 Feb 1999 10:43:47 -0500

On Wed, Feb 17, 1999 at 08:22:45PM +0800, David Luyer wrote:
> There appears to be a major bug in dlerror() or dlopen(); when I pass 
> dlopen() an invalid object (eg, an empty file) with a filename longer than
> around 22 characters, I get the first 21 or so characters of the filename
> followed by a random character out of dlerror().  The error message and the
> rest of the filename are nowhere to be seen.

Could you tar up a test case and put it somewhere on a web page, so
that we can reproduce the problem?

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|     CMU, CS class of 2002      |
|   Debian GNU/Linux Developer    __   Part-Time Systems Programmer  |
|         dan@debian.org         |  |        drow@cs.cmu.edu         |
\--------------------------------/  \--------------------------------/

Message #20 received at 33505@bugs.debian.org (full text, mbox, reply):

From: David Luyer <luyer@ucs.uwa.edu.au>

To: dan@debian.org

Cc: 33505@bugs.debian.org, zack@rabi.columbia.edu

Subject: Test case for bug 33505

Date: Thu, 18 Feb 1999 11:18:54 +0800

An example place it occurs...

ftp://typhaon.ucs.uwa.edu.au/pub/shm_program/shm_program-1.0.tgz

In one window:

typhaon; tar xzf shm_program-1.0.tgz
typhaon; cd shm_program-1.0
typhaon; ls
COPYING         README          dummy_client.c  shm_daemon.c
Makefile        cat_client.c    shm_client.c
typhaon; make
gcc -O2 -ansi -Wall -pedantic   -c shm_client.c -o shm_client.o
gcc -s -export-dynamic shm_client.o -ldl -o shm_client
gcc -O2 -ansi -Wall -pedantic  -s  shm_daemon.c   -o shm_daemon
gcc -O2 -ansi -Wall -pedantic -shared -s dummy_client.c -o dummy_client.so
gcc -O2 -ansi -Wall -pedantic -shared -s cat_client.c -o cat_client.so
typhaon; ./shm_daemon README README.shm
shmctl: Operation not permitted
WARNING: Continuing without locking down memory pages.
[daemon continues in foreground]

In a second window:

typhaon; ./shm_client README.shm ././././././././././././././dummy_client.so
Dummy client ready.  Press 'q' to quit or 'd' to dump shared memory.
Quitting ('q' found).
typhaon; ./shm_client README.shm ././././././././././././././COPYING
././././././././././

typhaon; ./shm_client README.shm ./././././././././././././COPYING
././././././././././

typhaon; ./shm_client README.shm ././././././././././././COPYING
././././././

typhaon; ./shm_client README.shm ./COPYING
./COPYING: invalid ELF header
typhaon;

So - it's a problem with dlerror() after a dlopen() of an invalid file.
As for the comment 22 or so characters is insanely short for a pathname
buffer - yes, but not if you're thinking it will always be a library
name.

(doesn't excuse the original poor coding, wherever it is, but may explain
it)

And the characte that the buffer gets on the end can be any kind of
random junk.

David.

Send a report that this bug log contains spam.