Bug 59978 - dynamic linker ld.so searches current working directory (cwd) for libraries when : is last item in LD_LIBRARY_PATH
dynamic linker ld.so searches current working directory (cwd) for libraries w...
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-17 09:33 EST by Joel Griffiths
Modified: 2007-04-18 12:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-17 09:33:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joel Griffiths 2002-02-17 09:33:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913

Description of problem:
When doing an ls on an NFS mounted directory (with wildcards - I'm lazy), I
noticed attempted mounts to i686, libc.so.6, libtermcap.so.2, and mmx in the
current working directory.

I search ld.so.conf and found nothing unusual. Next, I examined the
LD_LIBRARY_PATH variable and found only the adabas link added, when I installed
StarOffice, to my ~/.bashrc:

LD_LIBRARY_PATH="/home/joelg/adabas/lib:"
Here lies the problem.... The : at the end was added by the following .bashrc
commands:

# by Sun Microsystems setup
DBROOT=/home/joelg/adabas
DBWORK=/home/joelg/adabas/sql
DBCONFIG=/home/joelg/adabas/sql
PATH=$DBROOT/bin:$DBROOT/pgm:$PATH
LD_LIBRARY_PATH=$DBROOT/lib:$LD_LIBRARY_PATH
export DBROOT DBWORK DBCONFIG PATH LD_LIBRARY_PATH

I had nothing in my LD_LIBRARY_PATH, so a :[null]" was added to the end of my
LD_LIBRARY_PATH. I didn't think that the dynamic linker should interpret the
empty field as ${CWD}, but it does.

This seems like a nice way for a hacker with a shell account to break other
user's access (including root if StarOffice was installed or LD_LIBRARY_PATH was
set without checking it first).

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Install StarOffice or export LD_LIBRARY_PATH=/nada:
2.cd /tmp
3.strace ls
	

Actual Results:  The following dynamic libraries were loaded (or attempted to be
loaded) from the current working directory: i686  libc.so.6  libtermcap.so.2  mmx.

Expected Results:  Libraries loaded from place other than the CWD.

Additional info:

Here is an example of the affected portion of a strace:

# strace ls
execve("/bin/ls", ["ls"], [/* 31 vars */]) = 0
uname({sys="Linux", node="taz.aver-computer.com", ...}) = 0
brk(0)                                  = 0x80541a4
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/home/joelg/adabas/lib/i686/mmx/libtermcap.so.2", O_RDONLY) = -1 ENOENT
(No such file or directory)
stat64("/home/joelg/adabas/lib/i686/mmx", 0xbfffebbc) = -1 ENOENT (No such file
or directory)
open("/home/joelg/adabas/lib/i686/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64("/home/joelg/adabas/lib/i686", 0xbfffebbc) = -1 ENOENT (No such file or
directory)
open("/home/joelg/adabas/lib/mmx/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64("/home/joelg/adabas/lib/mmx", 0xbfffebbc) = -1 ENOENT (No such file or
directory)
open("/home/joelg/adabas/lib/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/home/joelg/adabas/lib", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
open("i686/mmx/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("i686/libtermcap.so.2", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("mmx/libtermcap.so.2", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("libtermcap.so.2", O_RDONLY)       = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3


I search ld.so.conf and found nothing unusual. Next, I examined the
LD_LIBRARY_PATH variable and found only the adabas link added, when I installed
StarOffice, to my ~/.bashrc:

LD_LIBRARY_PATH="/home/joelg/adabas/lib:"
Here lies the problem.... The : at the end was added by the following .bashrc
commands:

# by Sun Microsystems setup
DBROOT=/home/joelg/adabas
DBWORK=/home/joelg/adabas/sql
DBCONFIG=/home/joelg/adabas/sql
PATH=$DBROOT/bin:$DBROOT/pgm:$PATH
LD_LIBRARY_PATH=$DBROOT/lib:$LD_LIBRARY_PATH
export DBROOT DBWORK DBCONFIG PATH LD_LIBRARY_PATH

I had nothing in my LD_LIBRARY_PATH, so a :[null]" was added to the end of my
LD_LIBRARY_PATH. I didn't think that the dynamic linker should interpret the
empty field as ${CWD}, but it does.

I verified this in the following way:
[joelg@taz home]$ export LD_LIBRARY_PATH=/nada:
[joelg@taz home]$ env | grep LD_L
LD_LIBRARY_PATH=/nada:
[joelg@taz home]$ strace ls
execve("/bin/ls", ["ls"], [/* 31 vars */]) = 0
uname({sys="Linux", node="taz.aver-computer.com", ...}) = 0
brk(0)                                  = 0x80541a4
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/nada/i686/mmx/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64("/nada/i686/mmx", 0xbfffebcc)    = -1 ENOENT (No such file or directory)
open("/nada/i686/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/nada/i686", 0xbfffebcc)        = -1 ENOENT (No such file or directory)
open("/nada/mmx/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/nada/mmx", 0xbfffebcc)         = -1 ENOENT (No such file or directory)
open("/nada/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/nada", 0xbfffebcc)             = -1 ENOENT (No such file or directory)
open("i686/mmx/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("i686/libtermcap.so.2", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("mmx/libtermcap.so.2", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("libtermcap.so.2", O_RDONLY)       = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
Comment 1 Jakub Jelinek 2002-02-18 11:07:38 EST
This is a bug in Sun script, not anything else.
ELF Generic ABI mandates this behaviour.
The script should do something like:
test -n "$LD_LIBRARY_PATH" && LD_LIBRARY_PATH=":$LD_LIBRARY_PATH"
LD_LIBRARY_PATH="$DBROOT/lib:$LD_LIBRARY_PATH"

Note You need to log in before you can comment on or make changes to this bug.