590753 - (CVE-2010-3182) Insecure handling of LD_LIBRARY_PATH by run-mozilla.sh

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Dmitri Gribenko]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b5pre) Gecko/20100826 Firefox/4.0b5pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b5pre) Gecko/20100826 Firefox/4.0b5pre

Quoting ld-linux(8):
LD_LIBRARY_PATH
              A colon-separated list of directories in which to search for ELF libraries at execution-time.  Similar to the PATH environment variable.

All empty entries in LD_LIBRARY_PATH are treated like "." -- the current directory.  But an entirely empty LD_LIBRARY_PATH is not treated like "."  Having "." in LD_LIBRARY_PATH is pretty insecure, as it may lead to running arbitrary code.  Let's make a shared library:

$ cat lib.c
#include <stdio.h>

void my_init(void) __attribute__((constructor));
void my_init(void)
{
  printf("my_init()\n");
}
$ gcc -shared -fPIC lib.c -o librt.so.1

(/bin/ls and firefox-bin both depend on librt.so.1)

Running with empty LD_LIBRARY_PATH:

$ export LD_LIBRARY_PATH=
$ ls
lib.c  librt.so.1

Running with "." in LD_LIBRARY_PATH:

$ export LD_LIBRARY_PATH=.
$ ls
ls: ./librt.so.1: no version information available (required by ls)
my_init()
lib.c  librt.so.1

As you can see, standard /bin/ls program loaded librt.so.1 from current directory only the second time.

run-mozilla.sh changes LD_LIBRARY_PATH can add en empty entry to it if originally LD_LIBRARY_PATH was empty.  As all empty entries are equivalent to ".", we have a problem, because firefox will load libraries from current directory, while all other programs won't.

$ export LD_LIBRARY_PATH=
$ ls
lib.c  librt.so.1
$ ~/bin/firefox/firefox -no-remote -ProfileManager
/home/grib/bin/firefox/firefox-bin: librt.so.1: no version information available (required by /home/grib/bin/firefox/libxul.so)
/home/grib/bin/firefox/firefox-bin: librt.so.1: no version information available (required by /usr/lib/libgthread-2.0.so.0)
/home/grib/bin/firefox/firefox-bin: librt.so.1: no version information available (required by /usr/lib/libasound.so.2)
/home/grib/bin/firefox/firefox-bin: librt.so.1: no version information available (required by /lib/libdbus-1.so.3)
my_init()
/home/grib/bin/firefox/firefox-bin: relocation error: /home/grib/bin/firefox/libxul.so: symbol clock_gettime, version GLIBC_2.2.5 not defined in file librt.so.1 with link time reference

Here's a run with -d option so that run-mozilla.sh dumps its variables:

$ ~/bin/firefox/firefox -g -no-remote -ProfileManager
/home/grib/bin/firefox/run-mozilla.sh -g /home/grib/bin/firefox/firefox-bin -no-remote -ProfileManager
MOZILLA_FIVE_HOME=/home/grib/bin/firefox
  LD_LIBRARY_PATH=/home/grib/bin/firefox:/home/grib/bin/firefox/plugins:/home/grib/bin/firefox:
DISPLAY=:0.0
DYLD_LIBRARY_PATH=/home/grib/bin/firefox:/home/grib/bin/firefox
     LIBRARY_PATH=/home/grib/bin/firefox:/home/grib/bin/firefox/components:/home/grib/bin/firefox
       SHLIB_PATH=/home/grib/bin/firefox:/home/grib/bin/firefox
          LIBPATH=/home/grib/bin/firefox:/home/grib/bin/firefox
       ADDON_PATH=/home/grib/bin/firefox
      MOZ_PROGRAM=/home/grib/bin/firefox/firefox-bin
      MOZ_TOOLKIT=
        moz_debug=1
     moz_debugger=
moz_debugger_args=
/usr/bin/ddd  --gdb -- --args /home/grib/bin/firefox/firefox-bin -no-remote -ProfileManager

The vulnerability is that someone may trick the user to download a malicious library, the user might save it into his $HOME and after that start firefox from $HOME.

The fix is simple: replace ${var+":$var"} by ${var:+":$var"} expressions in run-mozilla.sh.  The difference is that the first expression expands to nothing only if var is unset, but the second expands to nothing if var is unset or var is empty.


Reproducible: Always

Comment 1

[Dmitri Gribenko]

Attachment: My proposed patch

Comment 2

[Benjamin Smedberg]

Comment on attachment 469244 [details] [diff] [review]
My proposed patch

How portable is this? I'm having trouble finding this expansion form in non-bash reference documentation.

Comment 3

[Dmitri Gribenko]

I think it is POSIX:

http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02

Comment 4

[Daniel Veditz [:dveditz]]

We'll take this on the older branches when it's good to go on the trunk.

Comment 5

[Daniel Veditz [:dveditz]]

Comment on attachment 469244 [details] [diff] [review]
My proposed patch

Approved for 1.9.2.10 and 1.9.1.13, a=dveditz for release-drivers

Comment 6

[Daniel Veditz [:dveditz]]

Since I don't recognize Dmitri, assuming checkin-needed?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/d4e3befbd494

Comment 8

[Reed Loden [:reed]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/51149d349784
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d0351a7d65e7

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Attachment: 1.8.0 version