307185 - URLs passed on the command line are parsed by the shell (bash).

Status: VERIFIED FIXED

(Core Graveyard :: Cmd-line Features, defect)

Description

[peterzelezny]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Galeon/1.3.21
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720

URLs passed on the command line e.g firefox <url> seem to be fed into the shell
(bash). This makes it pariticularly hard to reliably pass URLs to firefox from
external programs. Mozilla 1.7.10 (1.5.1-FC4) doesn't seem to be affected.

using: firefox-1.0.6-1.1.fc4


Reproducible: Always

Steps to Reproduce:
1. cd /
2. mozilla http://local\`find\`host (works fine, gives DNS error)
3. firefox http://local\`find\`host (executes find!)

Actual Results:  
The URLs backticks were parsed.

Comment 1

[Tuukka Tolvanen (sp3000)]

confirmed firefox MOZILLA_1_8 2005-09-01-14Z and suite 1.8b1

Comment 2

[Tuukka Tolvanen (sp3000)]

    moreargs=""
...
    while [ $# -gt 0 ]
    do
      case "$1" in
...
        *)
          moreargs="$moreargs \"$1\""
...
      esac
    done
...
    eval "set -- $moreargs"

The words in the string passed to eval for the non-option arguments to 'set'
need to be quoted. Putting double quote characters around something is not
quoting; double quotes quote very little. Putting single quotes around it and
substituting '\'' for each ' in the content would do, I think. A perhaps pretter
way would be to not construct a eval-able argument array string at all, but
instead work by rearranging options in the positional options array directly, so
no manual quoting is necessary.

Comment 3

[Tuukka Tolvanen (sp3000)]

Attachment: patch1: rearrange argument list (firefox only)

...like so. This would need to be done for the other instances of mozilla.in,
too, of course... http://lxr.mozilla.org/mozilla/search?string=moreargs

Comment 4

[hikaru1]

To demonstrate this problem with mozilla 1.7.10 it's a little more difficult
beacause the output of the command winds up going into the URL address bar.

try loading http://local`df`host - you'll wind up with the output going into the
URL bar, along with mozilla freaking about lots of things being invalid urls.

Just wanted to point out this problem is affecting both firefox and mozilla.

Comment 5

[Tuukka Tolvanen (sp3000)]

Attachment: patch2: all apps

here's a patch for all instances of $moreargs juggling that lxr found -- who
all does it need review from? I can't say I've tested all of these, but they
are rather identical.

Comment 6

[peterzelezny]

What is the next release version this is likely to be included in?

Comment 7

[Tuukka Tolvanen (sp3000)]

Attachment: aviary101 patch1

...if needed

Comment 8

[Tuukka Tolvanen (sp3000)]

Attachment: mozilla17 patch1

Comment 9

[Tuukka Tolvanen (sp3000)]

Attachment: trunk patch2.1

left one stray 'moreargs=""' in trunk patch2. carrying over r=benjamin

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Do those aviary1.0.1 and mozilla1.7 patch1s have the fix that's in trunk patch 2.1?

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

attachment 195797 [details] [diff] [review] landed on MOZILLA_1_7_BRANCH, 2005-09-20 14:08 -0700 (sorry
for forgetting to credit patch author in the checkin comment on this branch only).

attachment 195796 [details] [diff] [review] landed on AVIARY_1_0_1_20050124_BRANCH, 2005-09-20 14:10 -0700.

attachment 195798 [details] [diff] [review] landed on trunk, 2005-09-20 14:11 -0700.

attachment 195798 [details] [diff] [review] landed on MOZILLA_1_8_BRANCH, 2005-09-20 14:13 -0700.

Comment 12

[Tuukka Tolvanen (sp3000)]

> Do those aviary1.0.1 and mozilla1.7 patch1s have the fix that's in trunk patch
2.1?

they do.

> attachment 195797 [details] [diff] [review] [edit] landed on MOZILLA_1_7_BRANCH, 2005-09-20 14:08 -0700 

thanks.

Comment 13

[logan]

This also fixes bug 288378.

Comment 14

[Juha-Matti Laurio]

This was published as public 'High Risk'
http://www.frsirt.com/english/advisories/2005/1794 advisory on 21th Sep '05.

Comment 15

[Juha-Matti Laurio]

Correction:
on 20th Sep 2005, via FrSIRT mailing list 21:07:33 GMT and at FrSIRT web site
earlier.

Comment 16

[Juha-Matti Laurio]

Secunia said 'Extremely critical' (i.e. 5/5) http://secunia.com/advisories/16869/

Comment 17

[Steven V.]

Idealy, input validation should be done with a white list of allowed characters.
For example, if the supplied argument does not match a regex of
[a-zA-Z0-9:/\.=&\? %]* prompt the user or die with grace. Just a thought.

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

that wouldn't work for IDN.

Comment 19

[Tracy Walker [:tracy]]

verified with linux Mozilla 1.7.12 2005-09-20-17-1.7

Comment 20

[Jesse Ruderman]

See also bug 309551, same bug on Windows (with Cygwin).

Comment 21

[Arthur]

Don't forget that this affects TB as well. FF and the suite have been released
with the fixes. And
http://www.mozilla.org/projects/security/known-vulnerabilities.html is several
months out of date.

Comment 22

[Juha-Matti Laurio]

All SA16869, SA16846 and SA16901 advisories were rated as Extremely Critical.
CVE id for this issue is
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2968 .

Comment 23

[Marcia Knous [:marcia]]

I will verify that this is fixed in Tbird 1.0.7 on Monday when I have access to
a Linux machine.

(In reply to comment #21)
> Don't forget that this affects TB as well. FF and the suite have been released
> with the fixes. And
> http://www.mozilla.org/projects/security/known-vulnerabilities.html is several
> months out of date.

Comment 24

[Marcia Knous [:marcia]]

Verified on Linux using Thunderbird build 20050923-15

Comment 25

[Ceki Gulcu]

After installing FF 1.0.7 a few days ago, we noticed a problem which occurs with FF 1.0.7 (Linux platform) but not with FF 1.0.1 (Linux platform) not FF 1.0 (Windows XP).

We have a web-application which uses the GET method to fill a form. The application can be found at http://sudoku.qos.ch

When the user starts playing, he or she will interact with our application with the a URL of the following form:

http://sudoku.qos.ch/play.do;jsessionid=aAn3pQQOk69b?showCandidates=true&asString=1.586....8.9.2...7.3.4..21.9..3...2..81...53..7...6..1.17..4.\
6.2...3.4.5....751.9&candidatesAsString=%2C24%2C%2C%2C%2C379%2C39%2C49%2C34%2C%2C46%2C%2C15%2C%2C13%2C36%2C45%2C%2C67%2C%2C6%2C%2C59%2C79%2C%2C\
%2C68%2C%2C456%2C46%2C%2C1458%2C178%2C678%2C%2C468%2C46%2C%2C%2C279%2C49%2C279%2C%2C%2C46%2C345%2C%2C234%2C259%2C4589%2C%2C89%2C489%2C%2C35%2C%\
2C%2C29%2C89%2C%2C38%2C%2C238%2C%2C69%2C68%2C169%2C%2C189%2C%2C78%2C%2C346%2C46%2C3468%2C26%2C%2C%2C%2C8%2C&command=singleStep&autoPrune=true&b\
oxLockedOnLine=false&boxLockedOnColumn=false&coupleByLine=false&coupleByColumn=false&coupleByBox=false&showErrors=true

However, with FF 1.0.7 the URL is somehow transformed to:

http://sudoku.qos.ch/play.do?showCandidates=true&asString=123&candidatesAsString=123&command=singleStep&autoPrune=true&boxLockedOnLine=false&bo\
xLockedOnColumn=false&coupleByLine=false&coupleByColumn=false&coupleByBox=false&showErrors=true

The value for "asString" paramater becomes "123" instead of a much
longer (and correct) value.

As noted above, we are observing this problem only with FF 1.0.7 and
not with any other browser we have access to.