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

[hackstraw]

Yeah, they "fixed" it timely. But WHY THE HELL IS THERE A shell: SCHEME IN THE BROWSER IN THE FIRST PLACE? I've never heard of it, never needed it, and obviously there are issues with it.

Come on we blast M$ for putting vbscripting and whatnot in IE, but this is just as dumb.

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

[Anonymous Coward]

Bullshit. The same e-Week article points to the Bugzilla discussion. Since Bugzilla refuses links from slashdot, I have copied the first post for bug 167475. Note the date and tell me about the "clear advantage".

Opened: 2002-09-09 04:41 PDT

As we can see in bug 163648, external protocols can cause a lot of security
issues. But exploits for this bug are dangerous mainly if external protocol
handler is being requested automatically from HTML code via <IMG
SRC="externalprotocol:URL">, <IFRAME SRC="externalprotocol:URL"> and other
similar cases.

More, with relation to common sense, invoking an external protocol is absurd in
this case, because <ANYTAG SRC="..."> is request to return some data in browser,
not for launch external application.

So, disable external protocols in all cases, excluding <A HREF=>, can solve this
problem.

Marking severity critical according to 163648.

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

[Anonymous Coward]

Well, if you're going to brag about standards support, you need to support standards. Including the stupid ones.

Re:A clear advantage

[Wofser]

"#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." The problem is not who find out about it. The problem is that a big portion of the users dont upgrade. I mean the latest 4-5 big worms did not use any unknown exploits. It used old and well documented exploits, exploits that you could find example-code for. Copy-paste-compile!!

Re:A clear advantage

[mobets]

lol, you forgot the semicolon after the pritf line...

#include
int main()
{
printf("Hello World\n");
return 0;
}

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

[shellbeach]

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.

However much developer attention it received (and actually it wasn't much - see my comments below), it doesn't change the fact that this exploit was present for almost two years ... and a fix was only released when the bug received wider internet attention.

The speed with which a fix was issued after the general public was made aware of the problem was good ... but the previous activity over the bug (imagine setting the status to WONTFIX for this!!??) smacks of Microsoft-style negligence/lack-of-concern.

The specific comments you cite are indicative of this lack of concern- Comment #2 basically claims that it's not worth fixing security issues that are initiated without any form of user intervention whatsoever. And why? because it's easy enough to get a luser to click on a malicious link, so why should we worry about sites that just bypass the malicious click?? I don't know about everyone else here, but that sort of logic concerns me!

Just looking at the amount of interest in this bug after 2002 (only brief two comments in 2003 and another two in 2004; no patches submitted or even thought about) seems to suggest that if this had not been reported by the internet media this would never have been fixed. Or at least, not until exploits of it became commonplace.

And with the recent internet-banking trojans using a similar exploit (i.e. download and run malicious code without any user prompting) in IE, the issue seems serious enough to me to have warranted a quicker fix.

Re:A clear advantage

[johkir]

Another big difference between the two is the fact that Mozilla even uses a publicly available bug list - Bugzilla. Theoreticaly, we all have a list of potential exploits at our finger tips. Could you imagine a list like that for IE? Maybe that's just what they need.

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

[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

[tunah]

Bah, if they were really onto it, they would have embedded the exploit in the slashdot page and use it to patch your browser without clicking ANYTHING!

Re:A clear advantage

[TheDormouse]

Actually, important security bugs are not revealed to the public. They are only available to a handful of trusted developers. For some reason, they decided to "unhide" this bug after the fix was checked in for some reason.

Here we go again...

[LostCluster]

I can't help but think that this thread from earlier today can be seen as good news from a security context...

Just how does Mozilla/FireFox think it's going to keep malware from tricking the users into granting permission when the clueless masses come over from IE?

And this line says all I need to know

[GMFTatsujin]

"Researchers are reporting another security issue in Web browsing under Windows"

Sounds like a Windows problem, not a Mozilla problem. Oh, wait a minute...

Current versions of Mozilla and Firefox pass unknown protocol handlers to the operating system shell to handle.

Ding! Next. However:

The attacker would have to know the location in the file system of the program

So just in case, I'm renaming my /bin, /sbin, and /usr directories to /zurg, /mumph, and /splunge. Bring it, you haxx0rs!

Re:And this line says all I need to know

[Telex4]

The attacker would have to know the location in the file system of the program

So just in case, I'm renaming my /bin, /sbin, and /usr directories to /zurg, /mumph, and /splunge. Bring it, you haxx0rs!

Well now you've blown it!

Hint: Security through obscurity requires obscurity.

Huh?

[nettdata]

malicious persons are much more unlikely to target any vulnerabilites

I disagree... if anything, malicious people are MUCH more likely to target vulnerabilities.

Re:Blast!

[AuMatar]

Sure we have. I haven't seen an ME installation in years.

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)

This proves once and for all

[dicepackage]

How dangerous Mozilla can be. Everyone should be listening to Microsoft and use a secure browser such as Internet Explorer that isn't littered with security vulnerabilities.

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:It's not "in" the browser

[Switchback]

This shell extension could do just as much harm when running under a root Linux account (and there are plenty of those out there!)

Linux and Mac do not have such as thing to handle the "shell" protocol, thus it's not possible for them to have this flaw. Windows (in fact just 2000 and XP) are the only OSes that are vulnerable. Why? Because Microsoft wrote a dangerous handler that's not secure. If it was secure, no one would be talking about this right now. That fact that Microsoft themselves have fixed this bug in the next XP service pack doesn't tell you it's an MS bug?

Umm, that other protocol most likely won't have the ability to natively execute arbitrary strings passed to it! Maybe you're not understanding the difference between a native operating system shell handler and a text or image protocol handler.

I certainly understand it. It appears, however, that you do not. Mozilla is not arbitrarily launching a shell process merely because someone had a "shell:..." URI. It's asking the OS if it has an application that handles this protocol. Windows says yes and tells it how to launch the program. It passes the parameters to the application (just like any other helper app or plugin) and it's this application's responsiblility to check parameters. How is this any different than, say, registering my XYZ program to handle the "xyz" protocol and the XYZ application has a flaw that is exploitable?

Mozilla itself doesn't know one handler from another, and it shouldn't care. The system says "this application handles this protocol/content", so Mozilla hands it off.

Re:bias

[azadam]

"A serious security flaw has been found. But don't worry, it's no big deal!"

It's just frustrating to hear people whine about security via lower market share, but then excuse serious flaws using that logic when it's convenient.

I don't, however, refute the point. I'm just of the camp that would prefer stories to at least feign subjectivity, and leave the opinion for the comments.

Update system

[supercytro]

Whilst it's easy to take pot-shots at Microsoft when it comes to IE, their update system isn't too bad. Firefox needs a easy to use mechanism for automatically retreiving and installing critical update, in a manner similar to MS windows update service.

Even better, take a leaf out of Norton's liveupdate program.

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.

Intentional

[kyjello]

This is added intentionally so that Mozilla contains all of the features of Internet Explorer.

Oh yes, that's right! I went there.

Re:Just to be fair...

[plj]

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

Last weekend, I converted three people from IE6 to Moz FF 0.9.1, based on the facts that it's more secure than IE. And now I'm reading that it has a critical issue (whether it is a bug or not, but it is an issue). How to get their machines pached without my intervention? Where is that big red bouncing icon that appears when starting FF, which says that "you need to install this/these updates immediately to keep your machine secure"?

Hello, FF developers! Critical FF updates are not found on windowsupdate.microsoft.com! Where is your own auto-update feature?

Blacklisting vs. Whitelisting

[Temporal]

The developers considered changing from scheme blacklisting to whitelisting, in which case all schemes and protocols would be disallowed unless explicitly allowed.

Duh.

I have been saying this for some time now: Never use blacklists. Always use whitelists.

If you forget to put an insecure operation on a security blacklist, you have a security hole. If you forget something on a whitelist, you just have an inconvenience.

I am disappointed that the Mozilla developers did not have enough common sense to use whitelists in the first place. But then, it seems like most computer security schemes are blacklist-based, which explains why computers are so insecure.

Re:Bad way

[KevinKnSC]

Basically, you're passing on data from the windows URI handler... so it's almost like importing a windows IE/Web insecurity into Moz. Perhaps if Moz just imported the windows URI handlers as a datafile, and stripped out known baddies?

Relying on stripping out "known baddies" means that what you're really relying on is your list of known baddies. Any new baddie is, by definition, not on that list. Stripping them out is a start (web pages don't need access to shell://), but it's not a complete solution.

RTFBR

[jefu]

(Read the F-ing Bug Reports)

Reading the bugzilla entries for this and related bugs (an earlier post has the bugzilla url for this bug) is interesting in itself.

It shows that the developers well understood the security implications of the bug - but they were also trying to fit the browser into the MS scheme of things in which programs seem (I'm not a windows expert at that level) to be able to register protocols (shell:, vbscript:, irc:) that they get to handle. Disabling this in windows would then lead to Mozilla/Firefox behaving differently than they've come to expect.

It was further pointed out that mozilla could require a "yes" click in a dialog window, but that that would lead to other security issues.

Interesting reading.

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?)

This IS 100% Mozilla's fault

[MobyDisk]

...Is this really a security hole? When Mozilla receives a shell: request, it passes it on to an external handler in Windows. The "fix" for this is to disable this functionality...

I am shocked that everyone here is sticking on Mozilla's side. I love Mozilla, and have used it since the beta versions. I install it on mom & pop computers all the time for security. But this is definitely Mozilla's fault. Mozilla should not pass unknown protocols to explorer. IMHO, that defeats the purpose of Mozilla. That would be like coding Mozilla to pass ActiveX controls to Internet Explorer since it doesn't support them.

I treat Mozilla as a standalone app, and I consider that an advantage. I'm not vulnerable to scripting exploits, MS Office exploits, etc. But now I am told it passes some work to Explorer. I consider that a bug. I don't want it to pass everything except shell: to IE. I want it to pass nothing to IE.