Closed Bug 307185 Opened 15 years ago Closed 14 years ago

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

Categories

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

x86
Linux
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: peterzelezny, Assigned: tuukka.tolvanen)

References

Details

(Keywords: fixed-aviary1.0.7, fixed1.7.12, fixed1.8, Whiteboard: [sg:fix])

Attachments

(3 files, 2 obsolete files)

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.
Whiteboard: [sg:investigate]
confirmed firefox MOZILLA_1_8 2005-09-01-14Z and suite 1.8b1
Status: UNCONFIRMED → NEW
Ever confirmed: true
    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.
...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
Assignee: nobody → tuukka.tolvanen
Status: NEW → ASSIGNED
Attachment #195012 - Flags: review?(bryner)
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.
Attached patch patch2: all apps (obsolete) — Splinter Review
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.
Attachment #195012 - Attachment is obsolete: true
Attachment #195185 - Flags: review?(cls)
Attachment #195012 - Flags: review?(bryner)
Component: OS Integration → Cmd-line Features
Flags: review?(cls)
Product: Firefox → Core
Version: unspecified → Trunk
Attachment #195185 - Flags: review?(cls)
Attachment #195185 - Flags: review?(cls)
Attachment #195185 - Flags: superreview?(bryner)
Attachment #195185 - Flags: review?(benjamin)
Attachment #195185 - Flags: review?(benjamin) → review+
What is the next release version this is likely to be included in?
Attached patch aviary101 patch1Splinter Review
...if needed
Attached patch mozilla17 patch1Splinter Review
Attached patch trunk patch2.1Splinter Review
left one stray 'moreargs=""' in trunk patch2. carrying over r=benjamin
Attachment #195185 - Attachment is obsolete: true
Attachment #195798 - Flags: superreview?(bryner)
Attachment #195798 - Flags: review+
Attachment #195185 - Flags: superreview?(bryner)
Flags: blocking1.9a1+
Flags: blocking1.8b5+
Flags: blocking1.7.12+
Flags: blocking-aviary1.0.7+
Whiteboard: [sg:investigate] → [sg:fix]
Attachment #195798 - Flags: superreview?(bryner) → superreview+
Do those aviary1.0.1 and mozilla1.7 patch1s have the fix that's in trunk patch 2.1?
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.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
> 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.
This also fixes bug 288378.
This was published as public 'High Risk'
http://www.frsirt.com/english/advisories/2005/1794 advisory on 21th Sep '05.
Correction:
on 20th Sep 2005, via FrSIRT mailing list 21:07:33 GMT and at FrSIRT web site
earlier.
Secunia said 'Extremely critical' (i.e. 5/5) http://secunia.com/advisories/16869/
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.
that wouldn't work for IDN.
verified with linux Mozilla 1.7.12 2005-09-20-17-1.7
Status: RESOLVED → VERIFIED
See also bug 309551, same bug on Windows (with Cygwin).
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.
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 .
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.

Verified on Linux using Thunderbird build 20050923-15
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.

Blocks: 238710
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.