Mozilla/Firefox Bug Allows Arbitrary Program Execution

treefort writes "An article at eWeek has the lowdown. The article also has a link to the bug report which addressed this issue some time ago. Still, I feel safer using Firefox since malicious persons are much more unlikely to target any vulnerabilites. Note that this only affects users of Mozilla and Firefox on Windows XP or Windows 2000." New releases are already available on mozilla.org that fix this. Update: 07/09 00:41 GMT by CN : I removed the bum link to Bugzilla, since I guess they don't like us. Also I discovered that OSDN's own NewsForge has more on the situation.

Comments

A clear advantage

[SIGALRM]

The Mozilla Foundation has confirmed the problem and issued a fix

This incident underscores why many use or have switched to Firefox: vulnerabilities discovered and promptly fixed. Not weeks and months from their publication--and not by another vendor--this exploit was addressed by those who have made available Mozilla's code for public scrutiny.

FYI, in case you didn't read the article, you can download the fix here.

Re:A clear advantage

[Anonymous Coward]

This incident underscores why many use or have switched to Firefox: vulnerabilities discovered and promptly fixed. Not weeks and months from their publication

Yeah, it was years before it was addressed. If you read the Bugzilla report, it was first opened in 2002. This is not a good example of "open software fixes things faster".

Re:A clear advantage

[bwy]

Very true- no software ever written has been 100% bug free. Mac, Linux, Mozilla etc. simply aren't targets for obvious reasons that are frequently brought up here.

The difference in large part in my opinon boils down to:

#1 WHO finds the bug. Is it the developers and community that discovers it in good faith, or is it a hacker and the rest of us find out after a billion dollars has been lost worldwide to the latest worm, virus, etc.

#2 As you said, how quickly is the problem fixed. Certainly, private companies aren't necessarily horrible at doing this, to spite what people say. I work for a small software company and assure you that any security issues with our product would be corrected promptly. By the same token, some open source projects w/o a steady lead or direction could have exploits that go unfixed for some time.

However, based on my observations and considering those two points, I'd say I certainly feel better using Firefox than IE.

Re:A clear advantage

[lseltzer]

Not quite done yet. You have to restart your browser first.

Re:A clear advantage

[SIGALRM]

it was years before it was addressed

Not really. The bug history began immediately afterward and for quite some time it was moved between FIX and WONTFIX but received a lot of attention. Here are some of the comments from the bug report at http://bugzilla.mozilla.org/show_bug.cgi?id=167475 :

------- Additional Comment #2 From Jesse Ruderman 2002-09-11 16:58 PDT [reply] -------
It's not hard for a malicious site to get a visitor to click a link. Requiring
a click or an equivalent keyboard action can be useful for limiting how much a
web site can annoy you (pop-up windows, etc.) but I don't think it's useful for
larger security issues.

------- Additional Comment #3 From Daniel Veditz 2002-09-11 17:25 PDT [reply] -------
I agree, WONTFIX. Other bugs are already discussing blocking external protocol
handlers, we don't need to do additional work to base the decision on context.

------- Additional Comment #5 From Daniel Veditz 2002-09-12 11:35 PDT [reply] -------
re-opening for reconsideration. This doesn't solve the problem of untrusted
protocols, but even for trusted ones it doesn't make much sense in these kinds
of places.

Re:A clear advantage

[Maradine]

And for those who would like the actual URL . . .

http://bugzilla.mozilla.org/show_bug.cgi?id=1674 75

Forgive me. I'm an idiot when I'm flamebait.

Re:A clear advantage

[roca]

That is not a report of this or any other vulnerability. It's simply a suggestion for a change that would have provided a defense in case a vulnerability like this one was discovered. I agree we still should have done it, and hopefully will do it now...

Re:A clear advantage

[Anonymous Coward]

Valid point. Inspect the XPI before installing it. It's a ZIP file which contains two js files. "install.js" copies "bug250180.js" into the default-prefs folder. "bug250180.js" creates the preference string "network.protocol-handler.external.shell" with the value "false", which disables this particular handler.

The complete content of these files:

bug250180.js:

// block shell: protocol handler (bug250180)
pref("network.protocol-handler.extern al.shell", false);

install.js:

if (SUCCESS == initInstall("Patch for bug 250180","mozilla.org/bug250180","1.0.0.0"))
{
&n bsp; var prefDir = getFolder("Program", "defaults/pref");
var err = addFile( "", "bug250180.js", prefDir, "");

if (err == SUCCESS)
performInstall();
else
cancelInstall(err);
}

...or something similar to that, which I can't show here because Slashcode fucks it up.

Re:A clear advantage

[Anonymous Coward]

The bug listed in the summary is about a general issue - no actual exploit was known. When an exploit was made known YESTERDAY, bug 250180 was filed, and fixed within 24hrs.

Go to the source for better info!!!

http://www.mozilla.org/security/shell.html

Re:A clear advantage

[shaitand]

The debate on whether or not to do something about it was because it's the uri handler in the OS which is insecure, not mozilla.

This isn't really a fix for a security problem in Mozilla, it's a workaround for a security problem in windows... which is why this only affects Mozilla on windows.

Re:A clear advantage

[Aidtopia]

Except for the semicolon, as the other poster pointed out, this does have some portability problems. Not sure if you'd call them bugs or not.

#include<stdio.h>

You could argue that a preprocessor should allow this, some will indeed choke because there's no space before the <.

return 0;

The 0 is returned to the operating system, but operating systems have different rules for what return values mean. For example, in VMS, even numbers are errors, and

return 0;

will generate a nasty error message upon completion.

Some people argue that the compiler should return "success" when the code says to return a 0. I haven't read anything official that supports that. And if so, how would you return a 0 if that's indeed the error you need to return to the operating system?

For maximum portability with ANSI C, you probably want to do something like this:

#include <stdio.h>
#include <stdlib.h>

int main(void) /* void makes it clear this is ANSI, not K&R */
{
printf("Hello, World!"); /* note ',' for proper grammar */
exit(EXIT_SUCCESS);
/*NOTREACHED*/ /* Let lint know, that you won't get here. */
return 0; /* silences compiler warning */
}

[Slashcode says to use <ECODE> instead of <PRE or <CODE, but how do I inline code or do indentation with <ECODE>?]

Even his sig has a typo!

Re:A clear advantage

[mingot]

Could you imagine a list like that for IE?

Will probably end up happening soon. Open online bug tracking has already started for some of their products.

Re:A clear advantage

[mldl]

Actually http://bugzilla.mozilla.org/show_bug.cgi?id=250180 is the first mention of the shell: bug. Bug 167475 is a catch all deciding whether or not Mozilla/Firefox should hand off unknown protocols. If it used a whitelist of known protocols as some people suggest then it would break a lot of things relied upon over various platforms.

The specific shell: bug was reported only Wednesday morning which gives us a total time of less than 48 hours.

Re:A clear advantage

[TRACK-YOUR-POSITION]

Well, this is the bug you should probably be looking at: http://bugzilla.mozilla.org/show_bug.cgi?id=163648

One of the comments explains why this "bug" is so long in being "fixed"--it was suggested that a dialog should be popped up before launching any external app, (which Internet Explorer only started to do sometime this year), but this is inconsistent--external plugins, like Flash, don't get similar dialog boxes in any browser, even though such plugins have been exploited in the past. Also, some programs launch their own dialog warning the user of executing from untrusted environments, and having Mozilla also display a warning is redundant. Essentially, any program that registers itself as a plugin or web protocol is saying "I will take care of the security issues involved with my execution." Therefore, while known dangerous protocols like vbscript were blacklisted (that's why this particular bug is FIXED, even though the comments suggest awareness of the current problem), they didn't implement a whitelist (which I guess is the plan for 1.0) or a dialog box (which Internet Explorer now relies upon, foolishly) because it was not consistent with the behavior towards external plugins.

Presumably, with the bad press this has received, Mozilla has realized that Microsoft is going to put whatever-the-hell it wants to in as an external protocol, so unknown protocols should not be trusted. (Something that, apparently, Microsoft themselves has only realized in the last year or so.) shell: protocol is disabled in 0.9.2, and only whitelisted plugins will be trusted in 1.0. I think.

And now for some helpful links:

[strictnein]

And now for some helpful links:

Note: If you click on download links for firefox on the main page of mozilla.org, you get 0.9.2. The link on the firefox page @ http://www.mozilla.org/products/firefox/ still gets you 0.9.1. The link on the main page for the Linux version of Firefox still points to version 0.9.1. It seems that if you want 0.9.2 for Linux you'll have to compile it yourself.

0.8
0.9rc
0.9
0.9.1
0.9.2

And a direct link to the newest release for the really lazy:
Windows 0.9.2

The question is, what is the shellblock.xpi for?

Does Bugzilla know? Sorry, links to Bugzilla from Slashdot are disabled. Ook!

Re:And now for some helpful links:

[hallucination]

No need for a linux release..... Read the article:
Note that this only affects users of Mozilla and Firefox on Windows XP or Windows 2000

Re:And now for some helpful links:

[sgtsanity]

The shellblock.xpi works to patch the 0.9.1 release. The only difference between 0.9.2 and 0.9.1 is that one of the preferences is a different value by default. So, if you have 0.9.1 already, there is no need to download the 0.9.2 release. You can just patch it using the .xpi link on mozillazine.

Microsoft bug which affects Firefox

[Anonymous Coward]

This is NOT a firefox bug. It is a bug in an external protocol in windows - of which Mozilla calls. The fix is to disable ALL external windows protocols. (bittorrent, mirc, etc)

It's not "in" the browser

[Anonymous Coward]

Mozilla hands off schemes it doesn't know to the operating system (Windows), and WINDOWS executes the shell scheme. It was obviously a security flaw in their eyes, too, as they fixed it in XP SP2. If you were able to run Windows with real restricted user accounts, this wouldn't really be such a problem.

Re:It's not "in" the browser

[Switchback]

Agreed. It's not really a bug in the browser, it's a flaw in Windows.

Windows has a bunch of protocol handlers registered. Mozilla knows how to handle a few (e.g. http, ftp, etc.). Whenever it encounters a protocol it doens't know what to do with, it sees if Windows knows how to handle it. Windows either handles it in some way or it doesn't. If it doesn't, Mozilla puts up a message saying "xyz is not a registered protocol." Mozilla has no way of knowing that anything is bad or dangerous.

The real bug is in Windows. The only real options the Mozilla developers have is to black/white list known dangerous protocols or simply don't allow protocols Mozilla itself doesn't handle. Neither are optimal. If you can't trust the OS you're on, you really limit yourself, bugs or not.

So we banish the "shell" protocol today. Who's to say Windows won't have another flaw in another protocol tomorrow?

This really isn't any different than plugins, which are in a sense, external protocol handlers. i.e. they know how to handle certain content...just like a protocol handler. What if there is an exploit in a plugin? Mozilla just starts the plugin with the listed parameters and lets it go. Are you going to blame Mozilla for allowing the plugin to run, or are you going to require that Mozilla not allow "known, dangerous plugins" to run?

Re:Two beefs...

[hkfczrqj]

I don't like that the entire package had to be updated

I don't like that either. Nor the mozilla devs. So they posted a patch via an extension to be applied to ff, tb and seamonkey.

Cheers...

Incorrect bug link

[jesser]

Eweek and Slashdot linked to bug 167475, implying that Mozilla developers knew about this hole in 2002. Fixing bug 167475 would have done approximately nothing to protect Mozilla users against the shell: hole in Windows, and that is why bug 167475 hasn't been fixed.

The correct bug number for this hole is bug 250180.

Re:Open Source Collaboration

[roca]

That's not a report of this vulnerability. It's a comment about a proposed change that might have prevented this vulnerability, had it been implemented. At the time, there was no known actual vulnerability that demanded the change.

Re:Open Source Collaboration

[jesser]

That's not a report of this vulnerability. It's a comment about a proposed change that might have prevented this vulnerability, had it been implemented. At the time, there was no known actual vulnerability that demanded the change.

The proposed change wouldn't even have prevented this vulnerability. It would have increased the requirement to exploit it from "Get the victim to visit your site" to "Get the victim to visit your site and click a link".

Re:Open Source Collaboration

[Christopher Whitt]

As the other posters have said, all over, the bug was opened in Sept 2002. Not far from 2 years ago.

As other posters have been mistaken, so are you. The bug linked to in the /. article is 2 years old, but the correct bug (250180) is one day old. Fixing the 2 year old bug would have only removed some of the methods of activating the underlying Windows bug, not all.

Re:Update system

[galaga79]

There is an auto-update for Firefox, take a look at Options > Advanced > Software Updates.

By default it will periodically check for updates for the main program and extensions. You can even set it up to automatically download and install these updates.

Re:Just to be fair...

[Kelson]

But where is the auto-update feature for Firefox á la Windows XP, OS X, YAST or Up2date?

Tools -> Options -> Advanced -> Software Update.

To check manually: Tools -> Extensions -> Update.

It's not perfect yet, but remember, it's still 0.9.x, not 1.0.

(Wait, you did want an answer, right?)

Concern has been around since 2002

[DragonHawk]

The security exposure is apparently due to the fact that Mozilla, running on MS-Windows, will hand off any "URI scheme" Mozilla does not recognize to the OS. This only happens on MS-Windows. Since Windows may (and indeed, does, by default) know about URI schemes that do things you would not want a web page doing (like run programs), this is considered a problem for Mozilla.

I have to agree that this is a Mozilla issue. To use a slightly contrived comparison: I read my mail using UW Pine. If someone sends me a script via attachment in email, I do not want Pine to test and see if the interpreter in the she-bang line is available on the host OS. My OS is not my mail reader; I do not want my mail reader allowing everything my OS can do. Ditto my web browser.

There appear to be at least three Mozilla Bugzilla Bugs related to this (likely a lot more):

#1 = Mozilla Bug 163767 (20 Aug 2002)
"Pref to disable external protocol handlers"
http://bugzilla.mozilla.org/show_bug.cg i?id=163767

#2 = Mozilla Bug 167475 (9 Sep 2002)
"Disable external protocol handlers in all cases, excluding <A HREF"
http://bugzilla.mozilla.org/show_bug.cgi?id =167475

#3 = Mozilla Bug 250180 (7 Jul 2004)
"Shell: protocol allows access to local files"
http://bugzilla.mozilla.org/show_bug.cgi?i d=250180

It appears that Mozilla developers have been worried about this kind of problem going back to at least Aug 2002 (see #1 above). #1 talks about an option to disable external protocol handlers (URI schemes) by default. I have to say that would be the right thing to do. "Secure by default" is the correct approach.

#2 talks about an approach that uses context to determine if an external handler should be invokved. Basically, it assumes that if a user clicked a link, they wanted to invoke the handler; anything that happened implictly (such as image loading) should not invoke an external handler. I do agree with those who commented (in that bug) that this is not the right approach. It adds complexity, and it still fails to address the fact that clicking a link is not something that should just up and run anything the web page wants. If I wanted that, I'd use MSIE.

#3 is a reference to the "shell:" URI scheme in particular being abused this way. It blocks the "shell:" scheme to prevent that abuse. It does nothing to prevent abuses of other possible schemes, though. I suspect we may see this "feature" of Mozilla rear its ugly head again in the future.

This is not a failure of Open Source in particular. Nor does it prove Mozilla is crap or Microsoft is okay after all. It means that people make mistakes. This should not surprise anyone. Stop pointing fingers and fix the problem.

Re:Where's the patch for 2000?

[Lanzaa]

for FireFox:
1. type "about:config" in your url bar
2. Find "network.protocol-handler.external.shell"
3. Change value to false

Thats all that you need to do to fix it.

Re:Bad way

[dolphinling]

From the article:

The developers considered changing from scheme blacklisting to whitelisting, in which case all schemes and protocols would be disallowed unless explicitly allowed. Mozilla Foundation spokesmen said a future version of the browsers will change to whitelisting, but the interim fix just disables the shell protocol. Several other schemes, such as vbscript, are already disabled by default.

So in other words, this fix only changes a pref which is easy to do without a huge download, etc. and is easy for the clueless, since it requires one click. Future versions will have a fix for the problem in general, rather than just this specific case.