Asa Dotzler: Firefox and more

Look on the bright side, Asa. Now when people ask you which browser you use, you can say, "Double-oh-seven. Firefox two... double-oh-seven." At least for a few weeks until the next security update.

Does this affect quicktime alternative?

I like how Apple can rush out multiple iTunes DRM updates for those, uhh, malicious ringtones. But Quicktime, apparently not so much?

To Patrick: Yeah, good point. Hope, the next minor update will happen next year.

Related thoughts:

I want updates, when they are available, but I always cringe, when I update, as I run into this scenario *every* time:

- -

The following Extensions/Addons (whatever we call them these days), do not work with Firefox vX.X.X.X:

Extension A
Extension B
Extension C
Extension D
Extension E

Then, there is a "check for updates" button (which, unless the developer updated in the last 10 seconds, will fail), and then the "continue with out these extensions" option.

As a software developer myself, I certainly understand the challenge here.. and I know that extension developers can provide a range of supported point release upgrades that the extension *should* still work with.. but unfortunately, when developers are either (a) not informed of the update, or (b) not "pressured" to update their support list, the end users lose out.

For example in my case, I have a "CSSViewer", "Firefox View", "Snapper", "X-Ray" developer tools, that have all barked that they won't work on the latest version.

I'm 99.9% sure that *ALL* of them would work just fine on the latest version, but the "flag" tells Firefox that they should be disabled, because they are not supported.

- -

Long rant conclusion ;-)

It would be nice if Firefox, upon updating, if extension "XYZ" is not compatible, that the "Mozilla" servers get notified (once only), and an email is sent to the developer, as a gentle nudge... "hint, hint, please updtate your supported versions list, extension XYZ supports up to version 2.0.0.0 however Firefox is currently shipping version 2.0.0.7".

I'm sure the great minds at Mozilla can think of the most ideal method, but something to improve the user experience here would be greatly appreciated.

Otherwise, thanks for jumping in, when Apple was too busy launching iPhones to the UK. ;-)

Asa, I'm going to have to disagree with you here. Judging by what's on the security page, this is a problem of Ff not handling its command-line inputs correctly. Specifically, the line "QuickTime calls the browser in an unexpected way that bypasses that fix" tells me that a situation came up that the developers didn't plan for and the browser can be exploited as a result. Just like with the IE "bug", it's not another program's job to validate your input for you.

Besides, you can get Apple to fix QuickTime, but what about other programs? Can you guarantee that other programs won't do the same thing?

Probably the only way to really fix this problem is either not to accept this input, or to accept it very carefully. I'm not sure which method the developers finally adopted, but last time I looked, they were leaning toward something like the former.

Steve:

Extensions can indicate either the "maxVersion" they are compatible with with either a specific version ("2.0.0.6"), or by using a wildcard ("2.0.0.*"). Of the extensions you listed which are on AMO, all are using the wildcard (and one was 3.0+, so it's fine too).

I don't know why it's not working for you, but I've not had problems with this.

Steve, you make good points. I would have thought that most add-ons would not limit their compatibility with a minor 2.0.0.nn update, but who knows. Hae you tried the Nightly Tester Tools that adds menu items to make add-ons compatible?

Jason, I think you're wrong. A sophisticated program like Firefox SHOULD have all kinds of command-line options like it do all kinds of insecure things (mess with profiles, tweak chrome, even run a separate XUL app in 3.0). QuickTime should NEVER pass command-line options that it doesn't understand when it starts other applications. That's simply wrong.

Skierpage,
Read my previous note. If it's not QuickTime, it'll by IE. (Oops, it already was IE.) If it's not IE, it'll be something else (and probably is). Any program should NEVER be able to do anything harmful as a result of a command line.

VanillaMozilla, IMHO that is too utopical. First, because the very purpose of some applications is to perform some action through the command line; second, because it's not always easy to define what is "harmful".

Maybe the best (and real) fix, at least on Windows, would be to implement the asynchronous pluggable protocols API that Jesper Johansson suggested?
http://msinfluentials.com/blogs/jesper/archive/2007/07/10/blocking-the-firefox-gt-ie-0-day.aspx

Does this exploit work on other systems? Since Mac and Linux (and any other Unix-based system, for that matter) truly support arguments with arbitrary characters, I expected the whole string that QuickTime passed would be received as a single parameter…

A sophisticated program like Firefox SHOULD have all kinds of command-line options like it do all kinds of insecure things (mess with profiles, tweak chrome, even run a separate XUL app in 3.0). QuickTime should NEVER pass command-line options that it doesn't understand when it starts other applications.

Skierpage, if that were the case no program could ever start any other program via the command line -- it's an impossible task to know what every other program on earth considers good or bad, and the definitions of good and bad can change from version to version.

The only program that can truly know whether to accept a certain command-line input is the one receiving it. If the arguments are bad then it needs to either throw an exception or drop them on the floor. Ff is (was) doing neither, and was exploitable as a result.

You can see the results of saying it's somebody else's problem: First there was a "bug" in IE that left Ff exploitable, now it's a "bug" in QuickTime that does something similar. Why is it Apple's or Microsoft's responsibility to make sure that Firefox is written correctly? If this is a QuickTime bug, why is Firefox the only program affected by it?

Jason,

QuickTime knows what it needs to pass on the command line to launch Firefox, presumably firefox.exe {some_url}. (See http://kb.mozillazine.org/Command_line_arguments.) So that's what it does. It should NOT pass any other parameters on the command line to Firefox, that's simply maliciously clueless bad behavior.

Maybe you're confusing a potentially dangerous option (like -chrome) with a garbage value (all the various URL exploits over the years). Yes, Firefox should and does check its input. But if it's told to load chrome or a XUL app, it does it. How could it possibly prevent this? I guess Firefox could ship with two executables, firefox.exe and firefox_safe.exe, and tell other programs to start it up with firefox_safe.