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.
Steps to Reproduce:
1. cd /
2. mozilla http://local\`find\`host (works fine, gives DNS error)
3. firefox http://local\`find\`host (executes find!)
The URLs backticks were parsed.
confirmed firefox MOZILLA_1_8 2005-09-01-14Z and suite 1.8b1
while [ $# -gt 0 ]
case "$1" in
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.
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
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.
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.
What is the next release version this is likely to be included in?
Created attachment 195796 [details] [diff] [review]
Created attachment 195797 [details] [diff] [review]
Created attachment 195798 [details] [diff] [review]
left one stray 'moreargs=""' in trunk patch2. carrying over r=benjamin
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.
> Do those aviary1.0.1 and mozilla1.7 patch1s have the fix that's in trunk patch
> attachment 195797 [details] [diff] [review]  landed on MOZILLA_1_7_BRANCH, 2005-09-20 14:08 -0700
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.
on 20th Sep 2005, via FrSIRT mailing list 21:07:33 GMT and at FrSIRT web site
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
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
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:
However, with FF 1.0.7 the URL is somehow transformed to:
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.