238710 - mozilla 1.7b interprets shell caracters in url when launched from command line

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[hules]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20040130 Firebird/0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316

try mozilla 'http://$hostname' or mozilla 'http://plop.org/$(xeyes)'. With 1.6,
nothing is interpreted, with 1.7b, the url is replaced by the hostname, and
xeyes is launched.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Actual Results:  
a potential security problem


version 1.6 does not exhibit this problem. Firefox appears to have the same bug.

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Darin, any idea who should look at this/what might have caused this?

Comment 2

[Darin Fisher]

This is surely a side-effect of something in our shell scripts that launch
mozilla.  Maybe mozilla-xremote-client is involved, or maybe this has something
to do with the init.d changes?

Comment 3

[Roland Mainz]

I just tried a quick test with FireFox 0.8 on Solaris 2.8/SPARC (=/bin/sh is
plain bourne shell, not bash):
-- snip --
% export blabla=www.heise.de
% ./firefox 'http://$blabla'
% cat firefox | fgrep "init.d"
%
-- snip --
It seems that FireFox 0.8 suffers from the problem (and does not have the
"init.d" framework AFAIK).

Marking bug as CONFIRMED... ;-(

Comment 4

[Roland Mainz]

Debug output (e.g. shell script running with "set -x") from FireFox 0.8 on
Solaris 2.8/SPARC:
-- snip --
% ./firefox 'http://$blabla'
moz_libdir=/usr/local/lib/mozilla-1.6
MRE_HOME=/usr/local/lib/mre/mre-1.6
found=0
progname=./firefox
+ dirname ./firefox 
curdir=.
run_moz=./run-mozilla.sh
+ test -x ./run-mozilla.sh 
dist_bin=.
found=1
+ [ 1 = 0 ] 
script_args=
moreargs=
debugging=0
MOZILLA_BIN=firefox-bin
+ [ solaris = beos ] 
+ [ 1 -gt 0 ] 
moreargs= "http://$blabla"
+ shift 1 
+ [ 0 -gt 0 ] 
+ export MRE_HOME 
+ eval set --  "http://$blabla" 
+ set -- http://www.heise.de 
+ [ 0 = 1 ] 
+ exec ./run-mozilla.sh ./firefox-bin http://www.heise.de 
-- snip --

Comment 5

[Roland Mainz]

The following patch works around the problem:
-- snip --
--- browser/app/mozilla.in      26 Jul 2003 07:51:05 -0000      1.2
+++ browser/app/mozilla.in      7 Apr 2004 20:07:20 -0000
@@ -66,41 +66,41 @@
 fi
 if [ $found = 0 ]; then
   # Check default compile-time libdir
   if [ -x "$moz_libdir/run-mozilla.sh" ]; then
     dist_bin=$moz_libdir
   else 
     echo "Cannot find mozilla runtime directory. Exiting."
     exit 1
   fi
 fi
 
 script_args=""
 moreargs=""
 debugging=0
 MOZILLA_BIN="mozilla-bin"
 
 if [ "$OSTYPE" = "beos" ]; then
   mimeset -F $MOZILLA_BIN
 fi
 
-while [ $# -gt 0 ]
+while false
 do
   case "$1" in
     -p | -pure)
       MOZILLA_BIN="mozilla-bin.pure"
       shift
       ;;
     -g | --debug)
       script_args="$script_args -g"
       debugging=1
       shift
       ;;
     -d | --debugger)
       script_args="$script_args -d $2"
       shift 2
       ;;
     *)
       moreargs="$moreargs \"$1\""
       shift 1
       ;;
   esac
-- snip --

Later in the script is a "eval" statement:
-- snip --
export MRE_HOME
eval "set -- $moreargs"
if [ $debugging = 1 ]
then
  echo $dist_bin/run-mozilla.sh $script_args $dist_bin/$MOZILLA_BIN "$@"
fi
exec "$dist_bin/run-mozilla.sh" $script_args "$dist_bin/$MOZILLA_BIN" "$@"
-- snip --
This can only go wrong that way... ;-(

Comment 6

[Roland Mainz]

Attachment: Patch for FireFox 0.8

The patch seems to solve the problem but I have to test it more extensively.

I am still wondering why the script needs to override the content of the
argument array (e.g. $@) at all - was there a special reason for that ?

Comment 7

[chris hofmann]

anyone know if is this still a problem?

Comment 8

[Lucas Adamski [:ladamski]]

I can't get this to repro in 2.0.0.17 or 3.0.3.  I looked in the startup script for each and I don't see eval being used which appears to have caused the original issue.

Comment 9

[Daniel Veditz [:dveditz]]

This appears to have been fixed by the patch in bug 307185