Last Comment Bug 590753 - (CVE-2010-3182) Insecure handling of LD_LIBRARY_PATH by run-mozilla.sh
(CVE-2010-3182)
: Insecure handling of LD_LIBRARY_PATH by run-mozilla.sh
Status: RESOLVED FIXED
[sg:moderate]
:
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: x86_64 Linux
: -- normal (vote)
: ---
Assigned To: Dmitri Gribenko
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-25 15:53 PDT by Dmitri Gribenko
Modified: 2010-11-11 14:11 PST (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
final+
needed
.11-fixed
needed
.14-fixed


Attachments
My proposed patch (2.22 KB, patch)
2010-08-25 15:55 PDT, Dmitri Gribenko
benjamin: review+
bugzilla: approval2.0+
dveditz: approval1.9.2.11+
dveditz: approval1.9.1.14+
Details | Diff | Splinter Review
1.8.0 version (2.35 KB, patch)
2010-10-06 03:00 PDT, Martin Stránský
no flags Details | Diff | Splinter Review

Description Dmitri Gribenko 2010-08-25 15:53:02 PDT
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 2010-08-25 15:55:42 PDT
Created attachment 469244 [details] [diff] [review]
My proposed patch
Comment 2 Benjamin Smedberg [:bsmedberg] 2010-08-30 06:09:59 PDT
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 2010-08-30 08:06:41 PDT
I think it is POSIX:

http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02
Comment 4 Daniel Veditz [:dveditz] 2010-08-30 10:33:11 PDT
We'll take this on the older branches when it's good to go on the trunk.
Comment 5 Daniel Veditz [:dveditz] 2010-09-03 10:37:05 PDT
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] 2010-09-03 10:37:50 PDT
Since I don't recognize Dmitri, assuming checkin-needed?
Comment 7 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-09-06 02:48:52 PDT
http://hg.mozilla.org/mozilla-central/rev/d4e3befbd494
Comment 9 Martin Stránský 2010-10-06 03:00:59 PDT
Created attachment 481172 [details] [diff] [review]
1.8.0 version

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