Bug 59978

Summary: dynamic linker ld.so searches current working directory (cwd) for libraries when : is last item in LD_LIBRARY_PATH
Product: [Retired] Red Hat Linux Reporter: Joel Griffiths <joelgriffiths>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: fweimer
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-02-17 14:33:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Joel Griffiths 2002-02-17 14:33:29 UTC
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 16:07:38 UTC
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"