The same problem is valid for beagle (all wrappers), blam, tomboy, liferea,
maybe also for MONO_PATH for some of them.

This problem is more critical for programs, which can be click-started -
nautilus sets PWD to directory, where icon resides. It means, that clicking to
file in directory, where modified libc.so.6 resides means vulnerability.

For non-GNOME packages affected are FreeNX, wine, src_vipa.

Please note, that the list can be incomplete. I have checked only packages
installed on my desktop.

fgrep -B1 ':$LD_LIBRARY_PATH' {/usr,/opt/gnome,/opt/kde3}/{,s}bin/*
(search for scripts, where previous line is not else or if)

Adding FreeNX, wine and src_vipa maintainers to Cc:

I can change this for FreeNX, but I simply don't understand the problem, which 
will make it difficult for me to discuss/change it upstream. Why is it a 
problem to have LD_LIBRARY_PATH set to "<some_path>:" instead of "<some_path"?  

The problem is the fact, that that LD_LIBRARY_PATH="<some_path>:" is interpreted
as path containing two elements: <some_path> and current directory. If current
directory contains alien library, which is not present in <some_path>, it gets
precedence over system library.

How to repeat:
sbrabec@hammer:~> touch libc.so.6
sbrabec@hammer:~> tomboy
mono: error while loading shared libraries: libc.so.6: file too short

Indeed. I didn't know this (yet). Bug or feature? Or tradition? 

fixed (FreeNX). 

Should we provide a fix via YOU? Setting to NEEDINFO from security team.

Hack scenario: Imagine that somebody exports NFS volume. There is a directory
/home/hacker/MP3 with a lot of MP3 files and alien libc.so.6. You will open this
directory with Nautilus and click to one of MP3s -> Open with Banshee. You are
hacked.

yes, for all cases where the program is called by the user and not just  
defined lowlevel system 
(might not be the case for NX?) 
 
so all off banshee,beagle, etcetcetc need an update. 
 
(only the LD_LIBRARY_PATH change is approved by me for 10.0 all other bugfixes 
to those packages need to be approved seperately by AJ) 
 
SWAMPID: 2368 
 

please also fix the MONO_PATH instances. 

Can you take this Stanislav?

Banshee contains following construction:

I guess that it should not be installed as production binaries.

touch Makefile.am
touch ImLogViewer.exe
mkdir ../glue/.libs
cp -a hacked_libc.so.6 ../glue/.libs/libc.so.6

if [ -e ./ImLogViewer.exe ] && [ -e ./Makefile.am ] ; then
    echo "*** Running uninstalled ImLogViewer.exe ***"
    THIS_PATH="../Util:../images:../Lucene.Net"
    THIS_EXE="./ImLogViewer.exe"
    export LD_LIBRARY_PATH="../glue/.libs:$LD_LIBRARY_PATH"
else

i do not find this code in banshee in stable nor in 10.0. 
 
strange. 
 
This code should definitely not be in production settings. 

Fixed:

banshee: 10.0, STABLE
blam: 9.3, 10.0, STABLE
liferea: 10.0, STABLE
tomboy: 9.3, 10.0, STABLE

More packages will come.

To comment #12 - these wrappers are in tomboy and beagle.

Created attachment 51247 [details]
fix_paths

beagle: 9.3, 10.0, STABLE (removed exploitable uninstalled instance checks, the
same was done for variable MONO_GAC_PREFIX, added patch from bug 115329)

More packages will come.

Attaching semi-automatic fix generator.

Created attachment 51337 [details]
wine-secure-paths.patch

Proposed patch for wine. For wine there is also needed to change Makefile.in
echo about recommended command for profile. Patch fixes installed winelauncher
and uninstalled winewrapper.

For FreeNX, fix is already in STABLE.

Please decide, whether provide fix for released versions of Wine and FreeNX.

Please also decide about public security report.

I have submitted a fix upstream for WINE (winelauncher). I do not think a wine 
update is necessary, since nearly no one knows about this script. 
 
FreeNX ... how can it be called? I think it cannot be used within untrusted 
directories. 

I have digged /mounts/dist/unpacked/i386.full and got more vulnerable packages:

ardour: /usr/bin/ksi
scilab: /usr/bin/scilab
apache2: /usr/sbin/envvars /usr/sbin/envvars-std
src_vipa: /usr/sbin/src_vipa.sh
kdesdk3: /opt/kde3/bin/kde-build
mozilla: /opt/mozilla/bin/rebuild-databases.sh
MozillaFirefox: /opt/MozillaFirefox/bin/rebuild-databases.sh
sesam_srv: /opt/sesam/bin/sesam/sm_os_startup /opt/sesam/bin/sesam/sm_rmi_main

For many of them, it is probably enough to fix it in STABLE, but it needs to be
evaluated one by one.

wine: Could you fix echo in Makefile.in in top directory of wine, too? Thanks.

For already fixed GNOME packages, it should be probably reported to other
vendors, too and then fix it upstream.

the hit in kdesdk is no wrapper script but a developer script to build from 
CVS - as kde doesn't use CVS anymore, the script is pointless to have anyway. 
WONTFIX for that one 

submitted patchinfos for: beagle, blam, liferea, tomboy, banshee. 

To maintainers of other packages mentioned in comment 17:

Please check your packages. If the wrapper can be called by user from untrusted
directory as PWD, it needs security update. If not, fix in STABLE is enough.
Feel free to use script from comment 14, which will prepare raw fix for you (you
can need to replace . /czwork/etc/profile by /work/src/bin/.profile in suse.de;
patch sometimes needs minor editing).

The apache2 package contains /usr/sbin/envvars which is sourced by
apache2ctl. It is not sourced by rcapache2, but apache2ctl is the
community start script which very rudimentary but is packaged just in
case someone insists on using it. Thus, it is possible to call
apache2ctl from /tmp and step into this hole.

Created attachment 51760 [details]
proposed patch that I'm going to add

Documentation proposes profile making system vulnerable:

kdesdk3, kdevelop, tcm: 

More vulnerable scripts outside standard bindirs:

anjuta: /opt/gnome/share/anjuta/autogen.sh (no security impact, called from
project directory)
glade: /opt/gnome/share/glade-2/gtk/autogen.sh (no security impact, called from
project directory)
moneyplex: /opt/moneyplex/quicksetup.sh
ifolder3: /opt/novell/ifolder3/bin/ifolder (maybe causes bug 114293)
simias: /opt/novell/ifolder3/bin/simias
sesam_srv: /opt/sesam/bin/sesam/sm_os_startup /opt/sesam/bin/sesam/sm_rmi_main
opt/sesam/skel/templates/sesam2000.profile (in addition to above mentioned files)

Documentation proposes profile making system vulnerable:

xine-lib: /usr/share/doc/packages/xine/faq/faq.*
asc: /usr/share/doc/packages/asc/doc/linux_faq.html
NX: /usr/share/doc/packages/NX/samples/run-nxapp
itcl: /usr/share/doc/packages/itcl/README
libstdc++-devel: /usr/share/doc/packages/libstdc++-devel/html/faq/*
qt-devel-doc: /usr/share/doc/packages/qt/html/emb-running.html
sane: /usr/share/doc/packages/sane/sane-backends/README.solaris (not sure about
vulnerability of Solaris)
snack: /usr/share/doc/packages/snack/README
tcm: /usr/share/doc/packages/tcm/INSTALL /usr/share/doc/packages/tcm/usersguide/*
xqf: /usr/share/doc/packages/xqf/xqfdocs.html
howtoen*: many times
selflinux: many times
FlightGear-data: /usr/share/FlightGear/data/Docs/InstallGuide/html/getstartch4.html
dbxml-devel:
/usr/share/doc/packages/dbxml/examples/cxx/gettingStarted/Readme.txt
/usr/share/doc/packages/dbxml/examples/java/gettingStarted/Readme.txt
i4l-isdnlog: /usr/share/doc/packages/i4l-isdnlog/README
jai: /usr/share/doc/packages/jai/README-jai.txt
nap: /usr/share/doc/packages/nap/userguide.html
openh323-devel: /usr/share/doc/packages/openh323-devel/ReadMe.txt
socat: /usr/share/doc/packages/socat/FAQ

I think
/usr/share/doc/packages/sane/sane-backends/README.solaris
is a false-positive because it is only a documentation
how to build SANE on Solaris/x86.
To be 100% safe to have even no misleading documentation
I could change it for 10.1.

Stanislav,
to avoid false-positives:
Wouldn't it be sufficient to search only files which can be executed?

wouldn't it be easier to change the behaviour of ld.so? I don't see any 
reasonable use of implicit . in LD_LIBRARY_PATH 

Analysis of /mounts/dist/unpacked/i386.full should be complete now:

Vulnerable scripts in standard bindirs:

torcs: /usr/games/accc /usr/games/nfs2ac /usr/games/nfsperf /usr/games/texmapper
/usr/games/torcs (ugly but safe) /usr/games/trackgen (ugly but safe)

Vulnerable scripts outside standard bindirs:

postgresql-server: /etc/init.d/postgresql (nearly no security impact)
java-1_4_2-gcj-compat-devel: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/java
usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/bin/java
OpenOffice_org: /usr/lib/ooo-2.0/program/*
MozillaSunbird: /usr/lib/sunbird/rebuild-databases.sh (nearly no security impact)
TeXmacs: /usr/lib/TeXmacs/bin/tm_mupad_help
yast2-installation: /usr/lib/YaST2/startup/YaST2.First-Stage
nagios-plugins: /usr/lib/nagios/plugins/check_oracle
scilab: /usr/lib/scilab/bin/scilab

Documentation proposes profile making system vulnerable:

horde: /srv/www/htdocs/horde/scripts/sql/create.oci8.sql
qt3-devel-doc: /usr/lib/qt3/doc/html/emb-running.html
/usr/lib/qt3/doc/html/install-x11.html


To Johannes Meixner (comment #25):

AFAIK, category "Documentation proposes profile making system vulnerable" are
not false positives. Yes, it is not for YOU, but documentation should not
propose making whole system vulnerable to this bug.

I'd prefer ultimate solution.

BTW: What about other environment variables like PATH? ...

If no one intercedes, docu-maintainers should mail upstream for additional
documentation since this problem affects all distributions, I think.

(In reply to comment #29)
> BTW: What about other environment variables like PATH? ...

PATH="...:" causes a similar behaviour (in bash, exec{l,v}p() and 
which at least), but in most cases, PATH containts some value (in contrast to 
LD_LIBRARY_PATH), so a command like

export PATH="/blah/blah:$PATH"

shouldn't do anything bad, IMHO.

if $PATH is empty the shell also search in the current working directory for
binaries to execute. which is bad if root wants to exec "ls" in "/tmp". (old
example of executing trojan programs under unix)

Unfortunately empty $PATH components are defined in multiple places, where we 
cannot get rid of them. 
 
Empty $LD_LIBRARY_PATH components however perhaps could be caught since tehy 
are not useful. (Even though Andreas Schwab said that $LD_LIBRARY_PATH has the 
same definition as $PATH). 

ad comment 22: apache2 is fixed in STABLE.

comment 17:
- mozilla scripts are called by RPM / SUSEconfig only. no need to fix.
- ardour,scilab - fix in STABLE is sufficient.
- rest ... harmless, no need

comment 23:
- ifolder3, simias ... please fix at least STABLE
- rest ... harmless

comment 27:
- OOo ... fix in STABLE is sufficient, for older versions only if we do an update anyway
- rest is harmless

OOo wrappers have been fixed in STABLE. The fix will be also included in the planed update to OOo-2.0.0-final for SL 9.3 and SL 10.0.

i guess we covered the critical ones now.

I will close this bug :)

CVE-2005-4790

and also CVE-2005-4791  

CVE-2005-4791: CVSS v2 Base Score: 2.1 (AV:L/AC:L/Au:N/C:N/I:P/A:N)