Closed
Bug 590753
(CVE-2010-3182)
Opened 14 years ago
Closed 14 years ago
Insecure handling of LD_LIBRARY_PATH by run-mozilla.sh
Categories
(Core :: General, defect)
Tracking
()
People
(Reporter: gribozavr, Assigned: gribozavr)
Details
(Whiteboard: [sg:moderate])
Attachments
(2 files)
2.22 KB,
patch
|
benjamin
:
review+
johnath
:
approval2.0+
dveditz
:
approval1.9.2.11+
dveditz
:
approval1.9.1.14+
|
Details | Diff | Splinter Review |
2.35 KB,
patch
|
Details | Diff | Splinter Review |
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•14 years ago
|
||
Updated•14 years ago
|
Attachment #469244 -
Flags: review?(benjamin)
Comment 2•14 years ago
|
||
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•14 years ago
|
||
I think it is POSIX: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02
Updated•14 years ago
|
Assignee: nobody → gribozavr
Status: UNCONFIRMED → ASSIGNED
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
status1.9.1:
--- → ?
status1.9.2:
--- → ?
Ever confirmed: true
Comment 4•14 years ago
|
||
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
Whiteboard: [sg:moderate]
Updated•14 years ago
|
Attachment #469244 -
Flags: review?(benjamin) → review+
Updated•14 years ago
|
Updated•14 years ago
|
Attachment #469244 -
Flags: approval2.0?
Attachment #469244 -
Flags: approval1.9.2.10?
Attachment #469244 -
Flags: approval1.9.1.13?
Comment 5•14 years ago
|
||
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+
Comment 6•14 years ago
|
||
Since I don't recognize Dmitri, assuming checkin-needed?
Keywords: checkin-needed
Updated•14 years ago
|
Attachment #469244 -
Flags: approval2.0? → approval2.0+
Updated•14 years ago
|
Keywords: checkin-needed
Updated•14 years ago
|
Comment 8•14 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/51149d349784 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d0351a7d65e7
Updated•14 years ago
|
Alias: CVE-2010-3182
Comment 9•14 years ago
|
||
Updated•14 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•