Mozilla/Firefox Bug Allows Arbitrary Program Execution 940
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.
Only recent Mozilla bug. (Score:3, Interesting)
Re:Just to be fair... (Score:2, Interesting)
Re:A clear advantage (Score:5, Interesting)
Come on we blast M$ for putting vbscripting and whatnot in IE, but this is just as dumb.
Re:A clear advantage (Score:5, Interesting)
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.
Strange coincidence? (Score:3, Interesting)
Re:Open Source Collaboration (Score:2, Interesting)
------- 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.
Microsoft knew (Score:2, Interesting)
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:
They went with the second choice.
Re:A clear advantage (Score:4, Interesting)
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.
Bad way (Score:5, Interesting)
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:Just to be fair... (Score:5, Interesting)
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! [microsoft.com] Where is your own auto-update feature?
Re:Bad way (Score:5, Interesting)
Relying on stripping out "known baddies" means that what you're really relying on is your list of known baddies. Any new baddie is, by definition, not on that list. Stripping them out is a start (web pages don't need access to shell://), but it's not a complete solution.
RTFBR (Score:5, Interesting)
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:Bad way (Score:5, Interesting)
Re:It's not "in" the browser (Score:2, Interesting)
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.
This is headlined wrong... (Score:3, Interesting)
This has been addressed by MS (Score:3, Interesting)
Re:A clear advantage (Score:3, Interesting)
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 (Score:5, Interesting)
Re:Firefox pass unknown protocol handlers to the O (Score:2, Interesting)
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:Mozilla VS IE (Score:3, Interesting)
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:It's not "in" the browser (Score:3, Interesting)
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 (Score:3, Interesting)
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:Mozilla VS IE (Score:3, Interesting)
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:Bad way (Score:4, Interesting)
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 [mccanless.us]
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:This IS 100% Mozilla's fault (Score:3, Interesting)
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.
Simpler fix (Score:2, Interesting)
var prefs = Components.classes[ "@mozilla.org/preferences-service;1" ]
prefs.setBoolPref( "network.protocol-handler.external.shell", false );
prefs.getBoolPref( "network.protocol-handler.external.shell" );
Note: