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

VERIFIED FIXED

Status

Core Graveyard
Cmd-line Features
--
major
VERIFIED FIXED
12 years ago
8 years ago

People

(Reporter: peterzelezny, Assigned: Tuukka Tolvanen (sp3000))

Tracking

({fixed-aviary1.0.7, fixed1.7.12, fixed1.8})

Trunk
x86
Linux
fixed-aviary1.0.7, fixed1.7.12, fixed1.8
Bug Flags:
blocking1.7.12 +
blocking-aviary1.0.7 +
blocking1.8b5 +
blocking1.9a1 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix])

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

12 years ago
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.

Updated

12 years ago
Whiteboard: [sg:investigate]
(Assignee)

Comment 1

12 years ago
confirmed firefox MOZILLA_1_8 2005-09-01-14Z and suite 1.8b1
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

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

Comment 3

12 years ago
Created attachment 195012 [details] [diff] [review]
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
Assignee: nobody → tuukka.tolvanen
Status: NEW → ASSIGNED
Attachment #195012 - Flags: review?(bryner)

Comment 4

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

Comment 5

12 years ago
Created attachment 195185 [details] [diff] [review]
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.
Attachment #195012 - Attachment is obsolete: true
Attachment #195185 - Flags: review?(cls)
(Assignee)

Updated

12 years ago
Attachment #195012 - Flags: review?(bryner)
(Assignee)

Updated

12 years ago
Component: OS Integration → Cmd-line Features
Flags: review?(cls)
Product: Firefox → Core
Version: unspecified → Trunk
(Assignee)

Updated

12 years ago
Attachment #195185 - Flags: review?(cls)

Updated

12 years ago
Attachment #195185 - Flags: review?(cls)
(Assignee)

Updated

12 years ago
Attachment #195185 - Flags: superreview?(bryner)
Attachment #195185 - Flags: review?(benjamin)
Attachment #195185 - Flags: review?(benjamin) → review+
(Reporter)

Comment 6

12 years ago
What is the next release version this is likely to be included in?
(Assignee)

Comment 7

12 years ago
Created attachment 195796 [details] [diff] [review]
aviary101 patch1

...if needed
(Assignee)

Comment 8

12 years ago
Created attachment 195797 [details] [diff] [review]
mozilla17 patch1
(Assignee)

Comment 9

12 years ago
Created attachment 195798 [details] [diff] [review]
trunk patch2.1

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+
(Assignee)

Updated

12 years ago
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 #195798 - Flags: approval1.8b5+
Attachment #195797 - Flags: approval1.7.12+
Attachment #195796 - Flags: approval-aviary1.0.7+
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
Last Resolved: 12 years ago
Keywords: fixed-aviary1.0.7, fixed1.7.12, fixed1.8
Resolution: --- → FIXED
(Assignee)

Comment 12

12 years ago
> 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

12 years ago
This also fixes bug 288378.

Comment 14

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

Comment 15

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

Comment 16

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

Comment 17

12 years ago
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

Comment 20

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

Comment 21

12 years ago
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

12 years ago
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

Comment 25

12 years ago
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

Updated

8 years ago
Component: Cmd-line Features → Cmd-line Features
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.