Slashdot Mirror
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.
FYI, in case you didn't read the article, you can download the fix here.
Sigs cause cancer.
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!
Casual Games/Downloads
"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!
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?
"Researchers are reporting another security issue in Web browsing under Windows"
/bin, /sbin, and /usr directories to /zurg, /mumph, and /splunge. Bring it, you haxx0rs!
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
malicious persons are much more unlikely to target any vulnerabilites
I disagree... if anything, malicious people are MUCH more likely to target vulnerabilities.
$0.02 (CDN)
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)
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.
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.
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.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
Well, for all those who are browser-shopping, FireFox gets marked off the list of contenders. Who's next?
NCSA Mosaic?
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
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...
"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.
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.
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.
The shareholder is always right.
This is added intentionally so that Mozilla contains all of the features of Internet Explorer.
Oh yes, that's right! I went there.
kyjello is too damn smooth to make a signature.
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.
You're special forces then? That's great! I just love your olympics!
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.
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".
The shareholder is always right.
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?
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?
“Wait for Hurd if you want something real” –Linus
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.
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.
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.
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.
My server
As the other posters have said, all over, the bug was opened in Sept 2002. Not far from 2 years ago.
/. 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.
As other posters have been mistaken, so are you. The bug linked to in the
Mozilla
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...
If you don't like having choices made for you, you should start making your own. - Neal Stephenson
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?)
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.
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.
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.
g i?id=163767
d =167475
i d=250180
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.c
#2 = Mozilla Bug 167475 (9 Sep 2002)
"Disable external protocol handlers in all cases, excluding <A HREF"
http://bugzilla.mozilla.org/show_bug.cgi?i
#3 = Mozilla Bug 250180 (7 Jul 2004)
"Shell: protocol allows access to local files"
http://bugzilla.mozilla.org/show_bug.cgi?
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.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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
politics, food, music, life: FatMixx
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.)
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.
Never Smoke A Banana.