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

[peripatetic_bum]

OK. This just rocked. I click on the link to fix the exploit and mozilla asks if it can update the file and Whammo. It's done.

Amazing what the mozilla group is doing.

G

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

[lseltzer]

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

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

[Maradine]

Ummmm . . .

The vulnerability was first reported in September of 2002.

Sorry. RTFA and all that.

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

[Anonymous Coward]

No, the web page was tampered with and you are now broadcasting spam.

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

[0racle]

Problems in IE get a lot of attention too, but somehow every open bug is a blotch on MS, whereas for Mozilla here, its just fine and dandy.

Re:A clear advantage

[EvanED]

Oh, good. That makes me feel a lot better knowing that they were sitting around deciding not to fix it.

Re:A clear advantage

[ron_ivi]

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--....

But some people seem to be of the opinion that too many patches would be confusing.

"Ballmer said one key improvement will be a simplification of the way patches are distributed. Microsoft plans to move to a monthly patch release schedule, which he said will make it easier for network administrators to plan updates, which often require system shutdowns before installation."

If this other vendor is right that people want no more than monthly patches, such a fix may have to wait weeks.

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

[nacturation]

Very true- no software ever written has been 100% bug free.

Oh yeah???

• #include<stdio.h>

  int main()
  {

  • printf("Hello World\n")
    return 0;
  }

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

[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

[bwy]

The problem is that a big portion of the users dont upgrade.

One good thing, though. I've noticed a lot of larger companies are managing their desktops more tightly than they were a few years ago. Also shops running Citrix and Citrix-type environments have an advantage here... rather easy to make sure your users get the latest and greatest.

Home users are largely a lost cause however. Your average Joe isn't going to go out downloading update patches. The Windows Update or Software Update (Mac) type things work pretty well but I'm just not sure how many users use them and they don't cover 3rd party apps.

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

[owlstead]

Just to find out that the wrapper code and the stdio files are full of bugs, that the compiler is still in debug mode and opens up a remote socket to support it, the compiler is over-optimizing, the terminal on which the program runs is unstable, the code is P4 compatible but doesn't run on the intended platform... I mean, the code is not even bug free.

The problem with programs is that it is the complete _system_ that needs to be safe. As stated nicely by Bruce Sneider in one of his many books (I think it was Secrets & Lies (don't buy) or practical cryptography (must buy for security professionals).

Re:A clear advantage

[Sebastopol]

...AND forget to check the return value of printf. It really CAN fail.

Re:A clear advantage

[shaitand]

Actually this is a blotch on MS too, not Mozilla. The browser just passes unknown URI's to the OS and the OS handles them however it handles them. In this case the WINDOWS shell uri handler is insecure, creating what appears to be a bug in mozilla.

Re:A clear advantage

[CyanDisaster]

...no software ever written has been 100% bug free...

Uh...those aren't bugs. The program was supposed to do that. They're features. Yeah...that's it...features.

Hope be with ye,
Cyan

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

[Aldurn]

You forgot to HTML-escape the #include line, and you misspelled "printf" :)

#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello World\n");
return 0;
}

Re:A clear advantage

[mingot]

Would you use printf to diplay the error message if it did?

Re:A clear advantage

[dspeyer]

As they say...

Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work.

Incidentally, does the lack of proper interationalization in the original code count as a bug?

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

[Anonymous Coward]

Uh. This was a Windows-specific bug caused by the underlying OS. It's not a bug in Mozilla's code.

When you're writing cross platform code, and it that works perfectly fine on other platforms, and Microsoft keeps saying it's going to fix the bug, but stumbles around like a drunken barfly instead of releasing a fix... this is Mozilla's fault?

Microsoft says "Yeah, we're aware of that, we're going to fix it in SP2, it should be out Real Soon Now." and Mozilla takes them at their word, since it's their OS, and all applications on their OS are vulnerable to the bug, so it's in their best interest to get a fix out - and quick. Yet here's an OS bug that's been around since 2002 that Microsoft has made 0 public progress on.

And this is Mozilla's fault. For not making a hack to close an OS bug that the OS manufacturer should patch in a reasonably timely fashion. Yet doesn't. Yes, I agree, Mozilla is horrible, and Bill Gates is a saint. Yes.

BTW, could I have some of the pills you're taking? They sound wonderful.

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.

Re:A clear advantage

[Pieroxy]

Well, sure. I can write a small program that would execute any bash shell script when it sees one. It would be Linux's problem with it's naive way of executing all shell scripts when requested to do so.

Note that this program would show a strength of all windows systems, since this 'vulnerability' wouldn't apply to windows.

Your argument is a little flawed here, you must admit.

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

[jCaT]

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.

The longer known bugs are out there (and hell, even documented) the more time there is for someone to go out and actually write the exploit. Of course there won't be any exploits available when the bug is first found- unless the person who found the bug is the one who wrote the exploit (a rare case). I doubt in 2002 there was enough attention directed at mozilla to warrant a speedy bugfix, but since so many people are using it now it's under a lot more scrutiny. Now that mozilla is on the "radar" of crackers and other ne'er do wells out there, the exploits of known-but-not-fixed critical bugs are likely to start showing up more often.

Re:A clear advantage

[ak3ldama]

what i don't get is how people on slashdot can argue about a hello world example ... or why i'm even posting this

Re:A clear advantage

[shellbeach]

This isn't really a fix for a security problem in Mozilla, it's a workaround for a security problem in windows...

Well, regardless of the cause of the problem, if there's an exploitable hole it's still a security issue. Yes, it wasn't caused by some bad coding in Mozilla, but from reading the bug description and comments the exploit comes through HTML that has little or no valid use in legitimate, friendly web pages. (Hence it was possible for Mozilla to quickly release an all-blocking fix once it became publicised - disabling this funcitonality is not going to inconvenience anyone)

In that situation, it still seems negligent to me when you're failing to fix an exploitable hole once it's come to your attention and when there's no disadvantage to doing so.

As a very small-scale open-source developer myself, I feel that despite the GPL clauses about no warranty there's still something of a moral duty of care and trust in situations like this. Two years of being aware of this issue and doing little or nothing about it seems a bit worrying, IMO.

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.

Re:A clear advantage

[Jeffrey Baker]

no, but you might exit(EXIT_FAILURE); instead

Re:A clear advantage

[jesser]

We unhid the bug report because the hole had already been posted to the Full Disclosure mailing list.

Re:A clear advantage

[evilviper]

#include<stdio.h>

Ah HAH!

vi stdio.h
exec("rm", -rf /)

Muwahahahaha

Re:A clear advantage

[fodZ]

"How many people have had their machines turned into spam zombies because of this exploit?"

Wrong question.

How many thunderbird users COULD have their machines turned into zombies because of this kind of exploit?

Until THAT number is zero then saying "it hasn't happened yet" is like a 5 year old saying "but I didn't get run over" when told he shouldn't run across the road because he might get run over.

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:

[jesser]

shellblock.xpi fixes the hole in 0.9.1 so that 0.9.1 users don't have to download the whole browser again.

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.

Blast!

[darth_MALL]

"Note that this only affects users of Mozilla and Firefox on Windows XP or Windows 2000"...there goes a perfectly good Ha-Ha!. You've bested me this time *NIX...But you haven't seen the last of ME! BWAHAHA!

Re:Blast!

[AuMatar]

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

Re:Blast!

[mbourgon]

I feel safe, though... my 98 box is still immune.

Yes, but releases are available already

[Real Troll Talk]

Releases are available already. One of the (many) reasons I switched to the Gecko browsers from IE, because they actually update their software.

Note how fast it was patched compared to the fact that IE still doesn't have tabbed browsing.

Re:Yes, but releases are available already

[Anonymous Coward]

This particular bug has been in bugzilla for quite some time. Not sure why you think it was fixed "immediately". Remember, *you* just heard about the issue today and so the patch was not released in a timely fashion as you may believe. Awesome browser though no doubt!

Only recent Mozilla bug.

[homeobocks]

I guess that this is a big deal because I can't remember the last time Mozilla had a remote hole in it.

Re:Only recent Mozilla bug.

[Anonymous Coward]

It sounds like it is a Windows hole to me, not a Firefox one. Notice it doesn't work with XP SP2, meaning Microsoft has fixed the problem.

Re:Only recent Mozilla bug.

[Carnildo]

Strictly speaking, it's not a hole in Mozilla. It's a "feature" that can be used to turn local holes in other software into remote holes.

Re:Only recent Mozilla bug.

[bwt]

Actually, **Windows** has a hole in its API's that mozilla relied on. So mozilla patched themselves to eliminate a dependency on insecure MS code. In other words, mozilla is working around a microsoft caused security hole. If you use mozilla on linux (or a fixed version of windows), you aren't vulnerable.

Re:Only recent Mozilla bug.

[TiggsPanther]

What it looks to me like is that both sides screwed up. Mozilla/Firefox passing on requests to a known Windows vulnerability is not a smart move.

That said, as much as Mozilla should have looked into this earlier, so should Microsoft.

Now yes, Mozilla really should have done something about this ages ago. Defaulting to let any OS handle arbitrary protocols is a bad move, let alone Windows. However it seems that the moment it was published exactly how severe this vulnerability was they released both an updated version and a patch. That's definitely points in their favour. So old installs can be fixed and fresh installs can be more secure.

So far it looks like Mozilla have handled this well. Yes, they made an initial mistake, but they seem to have handled it well now. I just hope they can learn and not make any more mistakes like this. if they do learn better it will be major poitns in their favour.
What remains to be seen is what they'll do about protocol-handling in general. Have an option in the UI-menu to alter, add and remove protocols would be nice.

Tiggs

bias

[azadam]

"Still, I feel safer using Firefox since malicious persons are much more unlikely to target any vulnerabilites."

Seriously.

Re:bias

[bad_fx]

Seriously, what are you saying? That that statement isn't true?

Um, Seriously, if you think that's not true, you need to get your head examined - of course people are much less likely to target these vulnerabilities, because a much larger percentage of people currently use IE than firefox, not to mention that those who do use firefox are more likely to be at least slightly more savvy web users that their IE using conterparts. Hence there is less insentive for those with malicious intentions to target firefox (for now at least.)

So, how is the truth bias?

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.

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.

Re:And this line says all I need to know

[shaitand]

You know this doesn't affect any OS that uses /bin, /sbin, or /usr directories right?

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:Just to be fair...

[almostmanda]

who's leaving it unfixed?

Open Source Collaboration

[ZZeta]

Of course bugs will appear in Firefox.
Nobody in their right mind can expect a product to be perfect, but what makes Mozilla different is that bugs are fixed instantly. And that's because of the open source community, which is far more reliable than the competition.
People might disagree with me, but I still think these bugs (and their immediate fixes) only show how great open source really is.

Re:Open Source Collaboration

[rjstanford]

[W]what makes Mozilla different is that bugs are fixed instantly...

------- 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.

Er, yeah. Instantly. Cool.

Re:Open Source Collaboration

[EvanED]

bugs are fixed instantly.

Hmm, this is obviously some strange usage of the word instantly that I wasn't previously aware of...

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

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:Just to be fair...

[daeley]

Erm, the exploit is fixed. I hate hypocrisy as much as the next person, but RTFP.

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)

Re:Microsoft bug which affects Firefox

[DarkMan]

Bittorrent doesn't use the protocol handler. Instead, it relies on the browser identifing the .torrent through MIME types, and passing it to the client.

The external protocol handler would only be invoked if the links were like bt:// or bittorrent://. Never seen one like that.

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

[doorbot.com]

If you were able to run Windows with real restricted user accounts, this wouldn't really be such a problem.

This is working well for me, actually. I have two gripes though...

1. I can't add new VPN/Dialup connections easily. The New Connection wizard won't run as a regular user, and there doesn't appear to be a policy to allow this. However, I can add connections just fine through the Connections tab in the Internet Options control panel (although these connections are not firewall-enabled by default).

2. I can't adjust the power saving options, and again there doesn't appear to be a policy through which I could allow any user to adjust this. I have the policy set under the administrative account, but my own user account cannot make the changes (yet the "default" settings are *different* that what the administrator account had set -- So apprently I can override the admin settings but cannot override them with the settings I personally want.

There are other minor issues, like WinAmp doesn't save its preferences into my profile, but rather saves them to the Program Files\WinAmp directory. Granting permissions on the necessary files is not particularly difficult, however.

For games, I just install them as a subfolder in a \Games directory, which allows access to all local users. Sure, a virus running as my account could erase this stuff but the OS won't be damaged.

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

[soulhuntre]

"If you were able to run Windows with real restricted user accounts, this wouldn't really be such a problem."

You can. The fact that your either not familiar enough with it or too FUD bound to mention it doesn't change anything.

As long as OSS zealots keep fighting their IMAGE of MS software instead of what is actually out there they will continue to look like morons.

Re:It's not "in" the browser

[Switchback]

Yes, blame Microsoft. If you RTFA, you'd notice that Microsoft themselves fixed this bug in the next XP service pack (which won't be released for several more months...)

Mozilla's quickfix was to just turn the protocol off. The Mozilla developer's shouldn't be babysitting the Windows OS. It's an operating system protocol handler, just like any other registered helper app. What do you recommend happen if Flash has an exploit? Have Mozilla not load the flash plugin? No, it's a bug in Flash and we expect Macromedia to fix it. This is not any different. But in the mean time, since this shell handler is not really used, the quick fix is to simply ignore the shell protocol (i.e. don't hand it off to the OS).

The other fix is to dig into the registry and turn off the shell handler yourself.

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

[dekeji]

Mozilla hands off schemes it doesn't know to the operating system (Windows), and WINDOWS executes the shell scheme

The question remains: why does Mozilla "hand off" stuff from the Internet to the operating system? It obviously can't determine that doing so is safe, so it shouldn't do it.

If you were able to run Windows with real restricted user accounts, this wouldn't really be such a problem.

Oh, nonsense. Mozilla doesn't run with "real restricted user accounts" on UNIX/Linux either. The responsibility of deciding what is trusted and what is safe to "hand off" to the OS rests firmly with applications on most modern operating systems; every application programmer should know that, and it is not hard to program accordingly.

Re:It's not "in" the browser

[dekeji]

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.

Bingo.

Neither are optimal. If you can't trust the OS you're on, you really limit yourself, bugs or not.

What's there to trust? Does the Windows API spec state "you can safely pass any untrusted string from the Internet to the protocol handler and be assured that the system will not be compromised"? If it doesn't say that, you can't expect that it handles untrusted content without bad consequences.

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?

It is quite different. Plug-ins are specifically and explicitly designed for Internet content, but protocol handlers are already used for handling URLs that serve local purposes and may do destructive things. So, while the Flash plugin may have bugs, it actually tries to be secure no matter what content you hand it, but the protocol handlers don't.

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

No, it's not. If you want to fault Windows for something, you can fault it for not providing a protocol handler API that has a "trusted" boolean flag when you call it.

Re:It's not "in" the browser

[dekeji]

Because Microsoft wrote a dangerous handler that's not secure.

Do they guarantee anywhere that their handler API is secure against arbitrary Internet strings?

In fact, they don't, as should have been obvious to any developer who discovered the existence of shell:, which Mozilla developers did two years ago.

That fact that Microsoft themselves have fixed this bug in the next XP service pack doesn't tell you it's an MS bug?

No, it tells you that they are pragmatists.

(In any case, wouldn't you think that protocol handlers can be added via the registry anyway? So why would you expect this patch to make things secure?)

Mozilla should just handle the protocols it knows to handle and give an error message for everything else. What it is actually doing, handing off unknown things to the OS is just the sort of OS integration that causes so many problems for Microsoft applications as well.

Re:It's not "in" the browser

[Anonymous Coward]

What do you recommend happen if Flash has an exploit?
I expect you might start by not installing Flash by default.

Mozilla doesn't install Flash by default, and it doesn't install Windows by default either.

Seriously, if I was writing a web browser for Windows, no content would be passed straight to Windows without user intervention.

This page wants to display an image of type image/jpg [Ok] [Cancel]
This page wants to display an image of type image/gif [Ok] [Cancel]
This page wants to open an url of type news: [Ok] [Cancel]
This page wants to open an url of type mailto: [Ok] [Cancel]
This page wants to open an url of type irc: [Ok] [Cancel]
This page wants to open an url of type shell: [Ok] [Cancel]

Yeah, that would be an effective way to get people to move to Internet Explorer.

Obviously Windows has flaws and bugs. Is it the job of programmers to gripe and complain about these flaws or is it their job to deal with them?

A programmer is not supposed to sit in his own little closed world working around other peoples bugs without telling them about the bugs. Everyone will get much further with a little cooperation. So, Mozilla people tell everyone about an MS bug, some programmers not related to this story in any way make a workaround in their own software, and Microsoft gets the bug fixed in a few months. Everyone benifits. Your way would have everyone spending all their time working around eachothers bugs, without anything ever getting fixed, and in the end, nothing gets done.

Again I ask, does Opera have this flaw?

Why don't you check it yourself? I'm not putting that destructive piece of junk on my machine again. God know which files it will destroy next time.

Re:It's not "in" the browser

[Anonymous Coward]

No, they don't guarantee anything, so we shouldn't ever connect a windows machine to the internet?

This is a function to handle an URL. So, it gets used for handling an URL. Now, who would expect that the function really does "handle an url unless it starts with shell: In that case execute a shell command"? So, don't use that system call.

Which one will behave otherwise than expected/documented next time? Maybe a function to "display an image". It could just as well be "Display an image, unless the upper left pixel is red. In that case execute a shell command". So, we shouldn't pass anything off to Windows. Never use any system call. Back to DOS programming...

Re:It's not "in" the browser

[Technonotice_Dom]

Mozilla should just handle the protocols it knows to handle and give an error message for everything else. What it is actually doing, handing off unknown things to the OS is just the sort of OS integration that causes so many problems for Microsoft applications as well.

What about when you click on a 'mailto:' link? Do you want Mozilla to pop up and say it can't handle it? Or do you want it to use your default mail application to start up a compose message window?

Re:It's not "in" the browser

[FireFury03]

If the Mozilla guys knew about this all this time and decided to sit on it just because technically it was a problems with the OS, shame on them.

It was also "known" that MS had released a patch that claimed to fix this exact security problem with the OS... shame it didn't actually do that.

Re:It's not "in" the browser

[FireFury03]

why does Mozilla "hand off" stuff from the Internet to the operating system? It obviously can't determine that doing so is safe, so it shouldn't do it.

The OS contains a list of protocols and their handling applications. For example, RealPlayer will register itself and say "When someone clicks a link that calls for the rtsp: protocol then start me up coz I know how to handle it" (if this wasn't allowed then you could say goodbye to being able to just click a realaudio link and fire up the player). Unfortunately, Windows decided to add to the register an application saying "When someone clicks a link that calls for the shell: protocol, I know how to handle that".

Essentially there is a central register of "these applications can handle these internet protocols". As you know, anything on the internet has to be secure so this is basically a register of secure software. Unfortunately MS decided to put an insecure piece of software on the register and there was no reason for the browser to distrust the contents of the register.

hows is this different than file:///

[adamshelley]

in ie if i type

file:///c:/windows/system32/mspaint.exe

I can load the program, in firefox it prompts me to download it and disables the open option.

does this mean IE has always been vulerable to this type of bug?

Re:Just to be fair...

[Carnildo]

Strictly speaking, it's not an exploit in Mozilla/Firefox. It's a hole that can be used to access exploits in other software -- basically, it can turn what was a local exploit into a remote one.

Strange coincidence?

[hunterx11]

Isn't this a bit like the bug that Safari (and OS X URI handling in general) had earlier?

Re:Next!

[Carnildo]

Well, for all those who are browser-shopping, FireFox gets marked off the list of contenders. Who's next?

NCSA Mosaic?

No, it doesn't.

[SHEENmaster]

There are no known exploitations of this in the wild, so it in no way shows that attackers are going for the common denominator of Mozilla installations.

Also note that this is a problem with Windows URI Handler rather than Mozilla. Mozilla passes any protocol it doesn't understand to Windows, and Windows uses it to execute a local file. That's why this problem doesn't exist in anything but Windows.

This just goes to show that Microsoft makes insecure software, and that insecurity often bleeds into otherwise trustworthy programs.

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...

Re:Congratulations

[Jane_Dozey]

Please point out the hypocrasy.
I don't hear the OSS community pretending their software has no bugs or holes.

Monoculture, my ass.

[CaptainSuperBoy]

OK, that's it you guys. No more talk of how IE is so insecure because of Microsoft's 'monoculture.' Security issues, it seems, are a way of life in software. There are plenty of other arguments against Microsoft so there's no reason to use this one any more.

Personally I'm still going to use FireFox. It's a better browser than IE and I'm happy that they patched it in a single day. It's a little worrisome that this issue sat around on Bugzilla, hopefully this will motivate the Mozilla team to figure out some procedures to keep security bugs from slipping through the cracks.

Re:Thanks!

[Anonymous Coward]

Modded up for saying thanks?

Thanks for saying thanks! Thanks!

--
+4 'interesting'

Re:Sorry, links to Bugzilla from Slashdot are disa

[Charlie Bill]

That's why you need Mozilla with that handy "Launch This Page in IE" plugin. Referrer=null.

Re:Two beefs...

[maggeth]

There is a 2 KB patch available on Mozilla Update. Look for the ShellBlock extension.

And this is beta software. It's supposed to be buggy. The fact that IE is in it's 6.x series and still an open porthole to the world while today MozOrg fixed this issue in one day should say enough.

If you think there are any browsers out there that are totally secure, you're bleeding insane.

Re:2K or not 2K

[AchilleTalon]

RTFA to the end.

It explains the exploit is working with a specific syntax to invoke the program execution and it clearly mentionned the similar behavior for execution exists on W2K, but the syntax is different. Conclusion: The exploit exist only on WXP.

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.

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.

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:Incorrect bug link

[Platinum Dragon]

And if you read that bug #, it reveals that:

1) The problem is due to the shell: function, which passes the arguments to Windows XP for handling. The function was disabled in IE6 for the same reason it's being disabled in Moz/Fox now. In short, it's a hole in the Moz codebase caused by an insecure Windows capability. Thank you, well-paid Microsoft programmers.

2) The bug was opened on July 7. Today is July 8. One day.

Nice.

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:So who's going to tell all the recent converts?

[imogthe]

Well... We could always petition Microsoft to include Firefox/Mozilla in their Windows Update(TM) scheme :)

After that we'll move on to include the Gimp and OpenOffice. Before you can say "global domination" we'll have a perfectly good Microsoft Linux distro and whammo... 99% of the desktop belongs to the penguin.

But then again... maybe not.

Re:Firefox pass unknown protocol handlers to the O

[rjstanford]

Is it still security hole in Mozilla????

Yup. Because Mozilla, as a local application, has a much higher set of privs than a remote website does. This is basically taking code (high-level instructions, but code) from a known insecure zone and telling the OS to run it without any built-in safeguards. And what do you know: we have an exploit.

Here's a fun example of how IE gets it right. Take the URI file:///c:/windows/system32/mspaint.exe from another example on this discussion. Type that into start/run on a Windows box - it works. Type it into the Address bar of IE - it works. Toss it into a webpage on the local machine and click on it - it works. Toss that webpage onto a remote server and click on it - it doesn't work any more. Different behaviors for different levels of trust. Mozilla defeats this by passing things to the shell with the same level of trust as the user has given it, the local program, which includes the (necessary) ability to mess with the filesystem.

"updates available" bug fix

[joshds]

A lot of people have the problem where, even after they've updated to firefox 0.9.1 (or now 0.9.2) the automatic update still says that there is a new update available (annoying).

Here's the fix:

Enter about:config in the location bar.
Enter update.app in the filter field. (Click on Enter)
Reset any prefs that appear in bold.
Restart Firefox.


taken from FireFox support newsgroup. [http://www.mozilla.org/support/]

Microsoft knew

[Anonymous Coward]

Microsoft must have known about this hole, since Internet Explorer disallows the shell: protocol. When they found out about this hole, they had three choices:

1. Remove the shell: protocol, making all browsers secure.
2. Change Internet Explorer to disallow using the shell: protocol, leaving all other browsers vulnerable.
3. Change Internet Explorer to disallow using the shell: protocol and alert other browser makers to do the same.

They went with the second choice.

Taken out of context...

[Phil John]

...they didn't realise at that point that this could be launched without user interaction, that is what was posted to full disclosure - when that was written it was believed that a user had to be fooled into clicking on that link - a whole different ballgame.

True, I think this was something that should have been looked at earlier, but the same day the no-user interaction vuln was posted, there was a fix.

Is there a (proper) fix yet for the download.ject problem? No, even with the temporary "sticking plaster" that microsoft launched onto windows update this week there are still ways to exploit the problem. It will be months until a proper patch that fixes that will be released, if it is ever released at all.

Lets keep things in perspective and in context please.

Bad way

[phorm]

Which is basically to say:

IE bad because it is integrated into the OS
Moz bad because it calls the OS because it's not integrated

Both are bad. In fact, this is quite bad for Moz, as one of the touted improvements is that not being OS-integrated avoids such issues.

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?

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.

Re:Bad way

[phorm]

Well, the alternative to that would probably be to either not allow any that aren't known good (hey, how come this dumb browser won't open file X!), or allow all or all that aren't known bad but with a warning beforehand. Unfortunately, hoards of spyware/virus infested machines show up how well users pay attention to warnings/disclaimers/etc

Re:Bad way

[antiMStroll]

" Which is basically to say:..

Not at all. Mozilla falls down by trusting the multiple OSs it supports to securely handle something it doesn't understand. You did notice the part of the story that specifies this as a Mozilla/XP/2K exploit, right? No problem in Linux or *Bsd, etc., so I don't know how this OS intregration angle is relevant at all.

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.

Re:Bad way

[ttldkns]

so it's almost like importing a windows IE/Web insecurity into Moz.

It is in fact an IE insecurity too as i just tested it with internet explorer and windows 2000 at this link: http://www.mccanless.us/mozilla/mozilla_bugs.htm

so it is infact an OS vunerability and not browser specific. Infact, we have a patch and IE doesnt. That makes me feel good :)

Re:Bad way

[jrumney]

If I go to the download page I see a reference to 0.9.2 but no release notes telling me that there's a security problem.

0.9.1 was the same. The release notes were unchanged since 0.9 and there was just a note saying "minor bugfixes" in one place, and another note saying "critical update" somewhere else. Firefox is a great product, but they really need to do something about keeping users informed about their releases. We can't all be expected to browse through Bugzilla to see what has changed between releases.

Re:Bad way

[wellard1981]

I hate to be picky but isn't Firefox designed for XP / 2k

Mozilla is a cross-platform web browser, it has not been specificly designed to run on one type of operaing system, such as Windows. There are also packages for most flavors of Linux/UNIX, including the source code.

so you'd think the devs might consider security flaws in them to be an important issue.

What Mozilla are doing is passing anything that the browser does not understand over to the OS, with a small hope that the OS will understand what it means. The bug aparantly affects Internet Explorer too, so it's more of a bug in the Windows OS more than anything.

Re:Bad way

[stemcell]

As far as I'm aware IE does not directly run the shell: protocol but provides a dialogue offering the option to run / save / etc.

And yes, Mozilla is cross-platform, but Firesomething is designed for windows (with ports being a secondary consideration) - it doesn't seem unreasonable to expect some security protocol changes in light of that fact.

--
Stem

Re:Bad way

[rwise2112]

It is in fact an IE insecurity too as i just tested it with internet explorer and windows 2000

Odd! The article indicates:
The shell: syntax works only on Windows XP systems. According to one report, similar functionality is available on Windows 2000 but with different syntax.

Re:Bad way

[beeblebrox87]

Firefox is designed for Linux AND Windows. It has been the goal of the project to provide equivalent levels of support for both systems since it was called Phoenix.

IMHO, they should worry more about security with the Linux version than the Windows one, as anybody using Windows has pretty clearly shown that they don't care much about security anyway.

Heretic, YOU MUST BURN!

[Saeed al-Sahaf]

Heretic, YOU MUST BURN!

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:Blacklisting vs. Whitelisting

[ZorbaTHut]

Eww.

One of the big disadvantages to the whole blacklist/whitelist things is, indeed, inconvenience. But you seem to be thinking it's just a minor inconvenience where, to a lot of people, it's major.

Example: A while ago (I don't know if they still do, but it wouldn't surprise me) Unreal registered unreal:// to open games. You didn't have to do anything, it just worked. A lot of sites relied on this (click hyperlink, open unreal, badabing badaboom).

Now, if the web browser used a whitelist, there's a few options. First off, it could be utterly impossible for Unreal to register even with user assistance - bzzt, this is bad. Remember, users want things to be easy.

Second, it could require the user to go through the steps to add unreal:// to their settings. Also bad, because the Unreal coders don't want to have to change their installer every time the interface changes. Plus it's irritating for users. Bzzt.

Third, it could ask the browser/OS to register itself, and the browser/OS could pop up a confirmation box. But we already know users can be duped into clicking just about anything ("You MUST click Yes for real 100% hardcore xxx porn!") and so this wouldn't exactly be a rock-hard barrier. Bzzt.

Fourth, it can do what it does now, which is also flawed. Bzzt.

I personally think solution 3 is the best one - but if Windows doesn't already have hooks for things like this, it might not be practical for Mozilla to add a happy little dialog. There might be a way to query the system about what it *would* do it if we happened to pass it an unreal:// url, then prompt the user to see if that's what they really want to happen, but I bet that's exploitable also ("What's this rundll thing? Oh, the line says 'free porn'! I'll click yes")

I'd agree that more security = better (and more convenience = better too - the trick lies in balancing the two), but just saying "we should use a whitelist" leaves so much undecided that it's almost useless.

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:Konqui

[Maljin Jolt]

And how do you read your slashdot user page? It does not render properly (or sometimes at all) on Konqueror. As well as many other webs, because style engine is broken.

BTW, my Mozilla 1.7/linux on "shell:/bin/ls" says

Alert! shell is not a registered protocol

So, I see no problems with mozilla on linux.

Note, your Konqueror probably has some other obscure protocols, such as system:, settings: or programs: which may render your machine vulnerable by means you can't even imagine. You really should check if they are on just now.

Webpage should highlight the patch more

[klui]

It's really not obvious when you go to Mozilla.org that there's a patch available. It should be on the right-hand-side instead of down in the middle of the page on the left-hand side. Also, mozilla.org/products/firefox doesn't tell you there's a patch available!! Hopefully, my email to its webmaster will help fix this soon.

Some other fixes:

[twitter]

Note that Linux versions of these browsers were not exploitable. You can take advantage of this with free downloads from these helpful people:

• Mepis
• Fedora
• Debian use the new installer, Testing rocks.
• Feather Linux for those of you still running your favoite 486.

I doubt they will block Slashdotters.

It's less effort, really it is. We now return you, of your own volition, to Windoze hell.

Re:What moron put in "shell:"?

[CTho9305]

RTFBug. Since MS decided programs should be able to register protocol handlers (e.g. irc://, telnet://), Mozilla behaves like a good little windows program, and passes any unknown protocols (shell://, vbscript://) to the OS. It's a flaw in the whole setup that windows uses here, and MS changed the behavior for XP SP2.

Re:Shellblock XPI...

[Wanderer2]

How can I check it is installed?

Try this page: test page

After I installed the patch (without restarting Mozilla), all four example links were available to click on. Clicking on the fourth link, marked "Clicking this could crash your system!!!" did cause Mozilla to go crazy. It kept opening new windows stupidly fast until it crashed.

After it died, I restarted it and went back to the page - now three of the links are completely disabled (I can't even highlight them), and the link that does work (the one with the example iframe exploit) has no malicious effect - the iframe no longer shows the Windows tip but is empty instead.

So my version of Moz clearly wasn't fixed until it had been restarted.

This is headlined wrong...

[shaitand]

This is a windows hole, not a Mozilla hole. The Mozilla team has just decided to implement a workaround so the windows hole won't hurt you when using their browser. That is also why it only affects Mozilla on windows and why they debated whether to do something about it for so long.

Fix:

[mlk]

Download the fix here!

No problem for that other alternative browser...

[Rits]

Opera long ago decided to *not* pass on any protocol or scheme to the operating system, except for a few well defined cases (ftp, telnet, mailto). Users of Opera 7 can add specific protocols/schemes manually in the prefs if they want.

Lesson of today: there is always a danger in presenting yourself as 'the save alternative'. Proper engineering can reduce risks, but there are never garantees. Not that this example was especially worrying imho: you'd still have to be tricked to visit a specific website that plans to harm you. Not that likely unless you to tend to visit the bowels of the web...

This has been addressed by MS

[commodoresloat]

It requires clicking on a link in order to execute. MS has plainly addressed this vulnerability when it was a problem in IE, and their solution is the same for Mozilla.

Re:This has been addressed by MS

[HungSquirrel]

It requires clicking on a link in order to execute.

No, a sneaky little bastard could use <meta> refresh tags as well.

0.9.2 Release Notes?

[thedillybar]

Apparently they haven't gotten to writing the release notes for 0.9.2. Is this "shellblock" thing the only fix? Sounds like it would be much easier to install the shellblock.xpi extension. (redundant I know)

BUT, since I have XP SP2 installed (the latest release candidate), I can ignore 0.9.2 altogether? Or are other bug fixes included in this release?

Browsers

[AdmV0rl0n]

Having to run a windows site I was once again looking at the ADODB:stream bug and pondering directions to take and look into.

Some of the issues I pondered was if I spent a lot of time ripping out the user access to the none removable IE, and installing either Firefox, Mozilla, or another browser, or a combination of that or similar.

On the browser side, removal of Active X and the IE gubbins brings security, but also none working websites. Perhaps a lot of companies aare going to move back to the standards that form web rather than MS specific technology. I can't blame them, as most people outside tech areas like slash tend to use or aim for market leading pitches. The bulk of users use IE.

That will continue to be the issue, however, looking deeper into this, I looked at machines and figiured I would have to keep IE patched, but in addition, if I role another product or more, I merely add quite possible extra vectors of concern and attack.

All the browsers go through security and exploit issues, at least from time to time. What I settled on was continuing with IE. Its built into windows, there is'nt an easy undo for that.

Somewhere between Sunday/Monday, MS got a patch out. IMHO while this is not perhaps upto the highest levels of OSS error and fix correction, it is'nt bad or horrific.

In the main, so long as they deal with issues quickly and provide answers, I can tolerate them. They are not as bad as some make out.

The history of Mozilla is not as bug free and exploit free as much of the recent comments try to indicate. In truth, we will continue to have security issues with software, and it is how the vendor responds that should be critiqued.

AdmV

Im on pins and needles

[koan]

Waiting for the homeland propanganda......errr homeland security to advise us not to use it.

Re:Firefox pass unknown protocol handlers to the O

[roca]

Mozilla does support different levels of trust. For example, a page on a remote website can't create an IFRAME whose SRC points at your local filesystem. A local file can do that. So I don't know what your point is.

This bug is about which Windows HTTP protocol handlers should be trusted. 'shell:' was trusted when it should not have been.

Re:I knew it!!!

[TrancePhreak]

Avant Browser and MyIE 2 are both programs that make use of IE for displaying and both contain tabbed browsing.

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 bug report isn't the same..

[osssmkatz]

This bug report is about executing unknown protocol handlers in other places except . Mozilla has had for a while now, a blacklist of bad protocols that it should not pass to the OS.

With this patch, "shell:" was added--quickly because the infastructure was there.

--Sam

Damn straight it's a bug in Windows!

[argent]

Not only that, but it's a known (almost) ten year old bug in Windows - the use of the same set of handlers for local and remote services - and one I've been trying to tell people about for that long.

Mozilla and Firefox should NOT be using this functionality, they should be doing ALL their own URL parsing and handling on Windows, Linux, Mac OS X, and so on, because they can *not* depend on the native OS to do security right.

Even Apple doesn't do it right (see how they 'fixed' the help: problem), and Microsoft has refused to fix it on their side even under threat of judicial dismemberment.

From the article:

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 which, as far as I can tell, is totally unnecessary to begin with. External handlers -- programs outside Mozilla -- have no specific security model, so the only way to deal with them is to make individual exceptions like this one. Messy? Yes. But that's Windows.

The only way to deal with this is ONLY use external handlers you know are safe, rather than using all but the handlers you know have holes in them. Anything else is just following Microsoft's lead into a decade of virus-mania.

Re:WTF is an XPI? Super secret instructions requir

[Doppleganger]

Here you go.. an obvious, step-by-step guide.

Don't even need to double-click anything, it installs from inside the browser. No need for self-extracting executables.

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.

Re:This IS 100% Mozilla's fault

[spitzak]

I agree. This is a big screw up by Mozilla. The fact that Windows provides you with calls (like write()) that can damage your system does not mean the bug is in Windows, which seems to be the excuse being presented by everyone here. It is Mozilla's job to call such potentially destructive things only if it thinks it is safe.

Re:This IS 100% Mozilla's fault

[argent]

Mozilla should not pass unknown protocols to explorer.

Absolutely agree.

They do the same thing in Mac OS X, which is why the "help:" hole impacted Mozilla as well as Safari. It's 100% Mozilla's fault, and 100% Microsoft's fault. Both of them 100% ignored basic security.

Re:This IS 100% Mozilla's fault

[julesh]

As hundreds of other people have already pointed out, the bug filed 2 years ago, while it would have helped if it were fixed _would not have solved this problem_. Read it. It would have just stopped the use of and tags to open shell: URIs, not tags or form submissions, and probably not javascript either.

Also, the reported wasn't aware of this specific problem. One poster was aware of another protocol scheme that could be used to cause problems, which was subsuquently blocked -- i.e. they fixed the reason the problem reported was dangerous without fixing the "bug" itself. And, as fixing this "bug" would have damaged Mozilla's functionality, this is probably a good thing.

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.

auto-update no worky - ?

[real_smiff]

nice, doesn't seem to work though. says there are no updates, or it couldn't find any, something like that. for both methods you suggested (and for several other plugins i've got insalled). anyone else got firefox's auto-update to work?

Re:This is a Mozilla problem

[scenic]

Mozilla doesn't do what you described... it doesn't hand off any executable to the OS.

Your analogy isn't quite right... let's think about this another way... you have a plugin you've installed that has a security flaw in it. Is Mozilla (or IE or any other browser) responsible for the security flaw?

The registration of external protocol handlers is common practice across different platforms and browsers. I use OS X primarily at work and at home. I also run Linux here and have a Windows laptop at work. All three platforms use external protocol handlers to register helper applications.

The part that I think is significant is that the OS registered a protocol handler that isn't safe in an internet context. So, you either blame the browser for doing what the OS manufacturer recommends you do... or you blame the fool who wrote the insecure protocol handler (and why the hell would you want a "run any program" protocol handler????)

Sujal

Re:Serendipity! Vindication in under one day!

[Planesdragon]

You DO realize that there have been some rather high-profile bugs, malware, exploits, and viruses for Linux (and even BSD), don't you?

And you also realize that, if Gecko had only been put in Free Computing systems, it would have essentially rotted away to nothingness years ago.

Of course, you're also completely ignoring the amazing PR spin Mozilla is for Open Source. Sure, it has a bugs and holes--but those bugs are publicly filed, honestly reported, and fixed in a VERY timely fashion.

(Then again, you're comparing Free Computing and pregnancy.)

Accent Nazi!!

[wirelessbuzzers]

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

The French word à is spelled with a grave accent, rather than an acute one. If you're going to spell things like a smartass, at least get them right.

Re:Firefox pass unknown protocol handlers to the O

[archen]

Here's a fun example of how IE gets it right

That depends. While what you say is true, and it does not execute it also shows a lot about the thinking at MS. Mozilla hands off protocols to windows in a simplistic way because it is not a part of the OS - just as any other program does. IE by contrast has the concept of zones, and each zone has certain things which may be allowed or disallowed depending upon various security levels. This makes the IE security model much more complicated than it should be, and for most people hard to understand. And there has been more than enough problems with IE being confused as to which zone it's in, and enough exploits taking advantage of it.

Mozilla's fix is simple because what it does is simple. I'm not apologizing for the mozilla team here, and in fact I think it's sort of pathetc they just let this problem lay around for 2 years instead of just disabling the shell protocol to begin with. But if IE does anything right, it certainly is NOT the concept of security zones.

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.

How can I disable all external protocols

[MichaelCrawford]

Having looked over the relevant bug reports, I'm extremely uncomfortable allowing mozilla to use ANY external protocols.

Is there some way I can disable them all?

Re:Mozilla VS IE

[smash]

If you RTFA, you'll notice that the problem is with Windows explorer - Firefox is simply passing links handled by explorer.exe to windows.

Also, if you RTFA, you'd realise this was supposed to have been fixed in a Windows service pack, but isn't.

So yes, I blame microsoft :)

Problem doesn't exist on any other OS running firefox...

smash.

Re:Mozilla VS IE

[GISGEOLOGYGEEK]

ya ya ya, keep talking and prove my point more.

You are saying that the program that receives the malicious command should just blindly pass it along to windows, pass the buck, who cares about the consequences.

But when a MS product does anything like this all hell breaks loose, that the attack should have been prevented where it was received, not down the line.

warning, an analogy follows this statement, all analogies are inherently imperfect but I'm sure you will manage to get the damn point ....

Would you keep a firewall up that although secure in some ways, still simply passed an obvious very high risk command onwards for the operating system to deal with? umm do I even have to say the word NO?

But its OK, its an open source product, so passing the buck on is not considered evil the way it would be for an MS product.

Open your eyes, its a case of the open sourcers being totally unable to admit there could possibly be an 'MS style' fault with one of their products.

Re:Just to be fair...

[dolphinling]

Because shell: doesn't exist on Linux.

shell: is like any other protocol, such as http: or ftp:. What Necko (the networking part of Mozilla) does is if it doesn't recognize the protocol, it asks the OS. Windows recognizes shell:, and lets it do pretty much anything. None of the other OSs recognize it, which is why this only affects Windows

Why this is more Microsoft's fault than Mozilla's

[dolphinling]

There are two programs: one is the OS, the other is a user program, connected to the internet. There are four possibilities for (this part of) how they interact:

Neither of them checks to see if the input is coming from a trusted source Obviously bad, as was the case here Just the user program checks to see if the data is trusted Provides the security, but means this has to be implemented in every single user program Just the OS checks to see if the input is trusted Provides security, and only needs to be implemented once Both the OS and the user program check to see if the input is trusted Redundant, though arguably more secure

If you're paranoid, you should have both of them check to see if the data is trusted, otherwise just the OS should check.

My diagnosis is that this is a severe bug in Windows and is Microsoft's fault, however, since it was there, Mozilla should have blocked it from showing up.

The fact that once they realized it could be a problem they did block it is only a good thing.

Re:Firefox pass unknown protocol handlers to the O

[TheLink]

"Take the URI file:///c:/windows/system32/mspaint.exe Type it into the Address bar of IE - it works. Toss it into a webpage on the local machine and click on it - it works"

Doesn't work on mine. I see VERY few good reasons to need to be able to launch/download applications (or download fonts and run active script etc) from a local html page and thus I have disabled those options in the My Computer zone. I've also set things up so that copying and pasting gives me a prompt too.

Change the Flags to 1 in
HKEY_CURRENT_USER\Software\Microsoft\Windows\C urre ntVersion\Internet Settings\Zones\0

And the My Computer zone becomes configurable.

However do note that windows explorer seems to rely on activex or active scripting IF you are not using the classic view.

Re:Mozilla VS IE

[pe1chl]

Originally IE did the same thing as Mozilla does now, this was once identified as a bug/security issue, and then it was fixed in IE itself, not in Windows.
So others that have the same problem need to be fixed independently. This has now happened.

To know if IE really does not pass shell: urls, type one of these in your address bar:
shell:windows
shell:cookies

Re:Serendipity! Vindication in under one day!

[FireFury03]

Of course, you're also completely ignoring the amazing PR spin Mozilla is for Open Source. Sure, it has a bugs and holes--but those bugs are publicly filed, honestly reported, and fixed in a VERY timely fashion.

I really hope that if the mainstream media does stories on this they will make it clear that:
1. This is not a problem with the browser, it is a problem with the OS
2. The problem with the OS was alegedly fixed by a previous MS patch... except it wasn't - MS obviously don't test their patches.
3. Even though it was not Mozilla's own problem they still jumped and fixed it within a day of the report.
4. Microsoft knew about the latest IE hole 10 months before it was exploited and still did nothing about it.

The problem is in both

[brainnolo]

While surely this is a Windows bug, as is a normal procedure to pass to the OS the unknown protocols, Mozilla shouldn't really care of rtsp://, mirc://, and what not protocols. There are apps designed to handle that, and they register as helper apps for those protocols, so why Mozilla shouldn't trust them? How would Mozilla ever imagine there was a shell:// protocol? On the other hand it should probably do a white list of common protocols and issue a warning when clicking on an unknown one. If the user is just going to click OK on whatever he see, it becomes user's fault. The white list shouldn't be required, but it is in the moment you interact with components you don't know about. Think if they make a silent work registering for the URIs imaworm:// allowing attackers to do almost anything and the user wouldn't know if he doesn't see any significant slow-down, data loss, until they go on a malicious page. A browser shouldn't really whitelist anything more than http://, ftp://, rtsp:// and mailto. All the others should be user choices

wishful thinking

[rozz]

most of the answers modereated up around here are only wishful thinking .. people just love to fool themselves into "firefox is safer", no matter what ...lets see some samples

-- Still, I feel safer using Firefox since malicious persons are much more unlikely to target any vulnerabilites.
i wont bet a single cent on that ... plus this is like saying : i know i eat approximately the same shit as the other party, but im way better because mine gets no attention.

-- 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.
as Microsoft demonstrated in maaaaaaany occasions, IT DOES NOT MATTER how fast you release the patch.

-- This isn't really a fix for a security problem in Mozilla, it's a workaround for a security problem in windows.
it may be so .. but it sounds like : i live in an appartment building and its administrator's fault that any burglar can break into my appartment bare handed... so easy to blame "the other guy"

and so on.. and so on.
going mainstream was not exactly benefic to firefox ... i use it since the first version and this week i got the first pop-up and pop-under windows that somehow managed to slip through firefox' block mechanism ... and now this embarrasing flaw .. sadly, it seems that going mainstream its enough to evaporate the "security" of ANY application.

OT: mozilla support for exchange servers!

[mt-biker]

This is off-topic, but nonetheless should be of interest to mozilla users who are forced to use Outlook at work. Even more so for people who use linux at work and are forced to access email via Outlook Web Access (sob!).

Mozilla support for exchange servers (without IMAP) looks like it should now be implementable.

Bug 128284

Please vote for this bug if you desperately _desperately_ (like me!) need support for exchange!

Re:Mozilla VS IE

[Anonymous Brave Guy]

Mozilla's security record is no-where near as bad as IE's is - and won't get that bad, ever, due to different design decisions - whether its as popular as IE is, or not.

Y'see, the problem is that statements like that just don't have any credibility left when you're looking at vulnerabilities like this. The bug in question is a "complete wipe-out" style vulnerability. The issue was known by the Moz dev team years ago, and they decided it was WONTFIX. Yet even IE fixed this one a while back.

The problem here is not the specific bug, it's the attitude/lack of awareness demonstrated by the Mozilla dev team when faced with a critical vulnerability. The attitude of so many people in this thread -- "It's a Windows fault, not our precious Mozilla!" -- is almost as scary.

Sorry guys, the honeymoon's over. Mozilla can crash, can take out all your stored e-mail, can be exploited to damage the rest of your system, and doesn't get fatal security flaws fixed for years, just like IE. It may still be a better product, but there's no mileage left in claims that it will always and necessarily be so.

BTW, assuming there are no exploits out there for this vulnerability is staggeringly naive. Just because no widespread worm/virus-style exploits are known doesn't mean it hasn't been used by the geek who disliked the other guy down the hall or by the company emloyee wanting a quiet raise.

Re:This is a Mozilla problem

[hackstraw]

let's think about this another way... you have a plugin you've installed that has a security flaw in it. Is Mozilla (or IE or any other browser) responsible for the security flaw?

Look though my comment history and see what I think of plugins. (hint, they suck)

Yes, this is a mozilla problem. Here is the deal. When you develop an application where anyone in the world has input to that program you check the input for valid data and reject anything that is not valid. Period.

A uri handler called shell:// is stupid. Thats as if your leaving an open rsh or ssh port with no password. Again, this is the first time I've heard of such a handler, and I don't know exactly what it does or is supposed to do but the fact that its called shell tells me that its not something that belongs on an internet application. Name me one more network application that would accept arbitrary commands without a password to be run on a computer. Just one.

Re:This is a Mozilla problem

[scenic]

right, but how does mozilla know that a particular URL is not valid? So, "shell:" seems obvious to you, but it wasn't registered by Mozilla. Windows has a handler called shell. Mozilla is simply doing what the OS provider says to do... hand off unknown protocols to the local system to see if you have helper applications (for example, telnet:// or ssh://).

We agree about the stupidity of a shell:// handler... but Mozilla didn't provide it. I'm not sure what "valid data" they should be checking for here... the only thing I see at this point is that they need to start maintaining a black list of protocol schemes... Of course, if a particular bit of spyware/adware becomes popular, for example, they'll just be chasing down changing schemes.

Sujal

Re:Serendipity! Vindication in under one day!

[Epi-man]

Either go all the way to changing the OS AND the browser, do the right thing, all the way,or don't bother, it's naieve wishful thinking and at best a finger in the dike stopgap measure to try and make windows "secure" on the internet, and at best an incredible waste of time and resources in the OPEN source coding community.

I totally disagree with you. As a user that is stuck on an XP platform because where I work I have no say (and I am far from alone here!), I am absolutely overjoyed that the coding community "wastes" its time and resources to allow me to use my home browser at work. Last time I checked, the community was not out to "make windows 'secure'," but was instead out to make good software for people to use freely. Granted, I am probably starting another flamewar here (which free, blablabla), but I think you need to leave it to the people doing the coding to decide how to spend their time and energy and not foist alternate agendas upon them.

Re:Serendipity! Vindication in under one day!

[FireFury03]

What arrogance.

Does IE have this bug?
If not, it's a FIREFOX BUG...aka, it's a serious security flaw the Firefox browser has that other browsers due not.

As a matter of fact, the shell: bugs have plagued IE - this is a bug with the operating system that needs to be fixed at the source rather than _every single_ internet application needing a workaround.

I'm sure the typical arrogant "Firefox is impervious" argument will reign on Slashdot though..

I would never suggest that any software is completely secure - any programmer who believes otherwise is not worth employing. However, there is "less secure" and "more secure" - IE is a very insecure browser built ontop of (into) a very insecure operating system (mainly because MS take so long to fix problems after they've been discovered). Mozilla, FireFox, Opera, etc are reasonably secure browsers. Of course if you run an insecure OS then that compromises the security of everything running on it and there is only a limited amount of work those applications can do to correct for this.

The only real advantage Firefox has over IE is that it's more _defaultly_ secure.

Most of the people who get hit by the security problems are the people who do not know anything about security - they're the people who won't be selecting and deselecting options. Those of us who tweak the config ourselves are the reasonably safe ones so the default should be security. Additionally, installing ActiveX is a really stupid thing to do as it is the single biggest security hole in IE and is infact listed on the FireFox feature list as a security improvement by *NOT* running it.

Windows flaw...pish...if I put something in my browser that was capable of calling "rm -rf /", would you also blame the inventor of the rm program? Or how bout the shell? Maybe the OS? *smirk*

Windows holds a register of all the programs that can handle various internet protocols. Someone saw fit to add "shell:" to that register - whoever that was is to blame (and it sure as hell wasn't the browser)

Re:Hypocritical?

[timmyf2371]

Presumably it also affects the Netscape browser assuming Netscape is based on Mozilla, and Mozilla is a version 7 browser, IIRC?

Simpler fix

[dreadyco]

Instead of installing the extension, you could instead do this:

1. Open the Javscript Console
2. Copy the following line-by-line into the textbox (hitting enter after each line):
   
   var prefs = Components.classes[ "@mozilla.org/preferences-service;1" ] .getService() .QueryInterface( Components.interfaces.nsIPrefBranch );
   prefs.setBoolPref( "network.protocol-handler.external.shell", false );
   prefs.getBoolPref( "network.protocol-handler.external.shell" );
   

Note:

1. You shouldn't need to restart, it will be saved the next time you do, but the effect is immediate.
2. There are only 3 lines above, slashdot breaks the first line apart.
3. You should see a false after evaluating the 3rd line.
4. If you run into any trouble, start again from above.
5. If you have trouble with the slashdot-munged code above, go to my blog and copy it from the textarea.

Re:Serendipity! Vindication in under one day!

[dossen]

Does IE have this bug?
If not, it's a FIREFOX BUG

IE (version 6.0.2800.1106.xpsp2.030422-1633 (not kidding, that's what it says), which appears to be the latest version (no patches pending in the update utility)) opens shell: URIs. So the answer to your question is YES, IE has this bug