The default bug view has changed. See this FAQ.
Bug 590753 (CVE-2010-3182)

Insecure handling of LD_LIBRARY_PATH by run-mozilla.sh

RESOLVED FIXED

Status

()

Core
General
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: Dmitri Gribenko, Assigned: Dmitri Gribenko)

Tracking

unspecified
x86_64
Linux
Points:
---

Firefox Tracking Flags

(blocking2.0 final+, blocking1.9.2 needed, status1.9.2 .11-fixed, blocking1.9.1 needed, status1.9.1 .14-fixed)

Details

(Whiteboard: [sg:moderate])

Attachments

(2 attachments)

(Assignee)

Description

7 years ago
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
(Assignee)

Comment 1

7 years ago
Created attachment 469244 [details] [diff] [review]
My proposed patch
Attachment #469244 - Flags: review?(benjamin)
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.
(Assignee)

Comment 3

7 years ago
I think it is POSIX:

http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02
Assignee: nobody → gribozavr
Status: UNCONFIRMED → ASSIGNED
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
status1.9.1: --- → ?
status1.9.2: --- → ?
status2.0: --- → ?
Ever confirmed: true
We'll take this on the older branches when it's good to go on the trunk.
blocking1.9.1: ? → needed
blocking1.9.2: ? → needed
status1.9.1: ? → .13-fixed
status1.9.2: ? → wanted
Whiteboard: [sg:moderate]
Attachment #469244 - Flags: review?(benjamin) → review+
status1.9.1: .13-fixed → ?
Attachment #469244 - Flags: approval2.0?
Attachment #469244 - Flags: approval1.9.2.10?
Attachment #469244 - Flags: approval1.9.1.13?
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
Attachment #469244 - Flags: approval1.9.2.10?
Attachment #469244 - Flags: approval1.9.2.10+
Attachment #469244 - Flags: approval1.9.1.13?
Attachment #469244 - Flags: approval1.9.1.13+
Since I don't recognize Dmitri, assuming checkin-needed?
status1.9.1: ? → wanted
Keywords: checkin-needed
Attachment #469244 - Flags: approval2.0? → approval2.0+
http://hg.mozilla.org/mozilla-central/rev/d4e3befbd494
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Keywords: checkin-needed
blocking2.0: ? → final+
status2.0: ? → ---
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/51149d349784
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d0351a7d65e7
status1.9.1: wanted → .14-fixed
status1.9.2: wanted → .11-fixed
Keywords: checkin-needed
Alias: CVE-2010-3182

Comment 9

7 years ago
Created attachment 481172 [details] [diff] [review]
1.8.0 version
Group: core-security
You need to log in before you can comment on or make changes to this bug.