Firefox 0.9.2, Thunderbird 0.7.2, Mozilla 1.7.1 Coming SoonThursday July 8th, 2004Branches have been created for three of mozilla.org's latest releases, in order to fix an external Windows protocol handler bug. The fix involves disabling the More information about the exploit can be found in this post on the FullDisclosure mailing list. Update: The XPI to disable the pref is now available. Another Update: mozilla.org has published a document on the issue. Yet Another Update: There is an eWeek article about the exploit as well as a discussion at Slashdot. The now public bug report that covers the Yet Another Update: If you are not using Windows, you are not at risk from this bug. If you are using Windows, go to www.mccanless.us/mozilla/mozilla_bugs.htm to see if you are vulnerable. It sounds like this is a perfect canidate for the new auto update feature. I dunno, to minimize the testing needed, they may just make this one change. If this is the only change, there's prolly not much of a reason to release linux/mac 0.9.2... I'm not so sure. :( Everyone that I know of that either upgraded or first-time installed Mozilla Firefox 0.9.x, I showed them how to disable the auto-update feature to prevent bugs. I discovered two bugs while trying to set the preference mentioned. 1) When I typed "shell" into the Filter textbox and discovered that the pref did not yet exist, I tried to right-click to get a context menu so I could add the new pref. No context menu appeared! I later figured out that you need to actually right-click on an existing pref to add a new (unrelated) pref. This is bug 238955 <http://bugzilla.mozilla.org/show_bug.cgi?id=238955>. 2) When I added the new pref, I was using the filter "network.p". After adding the pref, it did not appear in the filtered list as it should have. I had to re-filter the list to get the new pref to show up. Can someone find the bug number for this? this is why I love firefox...took no time at all to fix this. download of patch and applying it took seconds. "this is why I love firefox...took no time at all to fix this. download of patch and applying it took seconds." The only reason that you could do that was because the fix is a simple pref change. If it say, required a change to the way the core networking libraries operate, you'd likely be looking at a complete new build. Alex Hmmm ... I'm not so pleased. I, too, had thought to use about:config to reset the value and was surprised not to see it. I grant that it's nice that the xpi patches it so easily, but how many mainstream users come to Mozillazine.org every day? There ought to be a pop-up alert: Critical security update required, Download now! I also am troubled that new preference items can so easily be created in about:config . What prevents malware from creating a new entry expressly designed to open the door to an exploit? I have installed the 0.9.2 nightly: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2 I noticed that the server directory from which I obtained this nightly has an xpi subdirectory, but I did not d/l anything from that subdir. Does 0.9.2 by itself contain all the necessary security fixes, or do I need some of those xpi files? Do I still need the xpi file linked above ("XPI to disable the pref is now available") ? 0.92 disables the potential security problem. OK, will 0.9.1 alert me when 0.9.2 comes out?? I had 0.9 & it never told me when .1 shipped.. This does seem like a huge issue though, does it actually run .exes or just download them? "...which was found to enable pages to run executables on Windows via a link." It does NOT download executables. However it apparantly allows someone to run an arbitrary executable, which is by itself already dangerous enough. As for the auto-update not kicking in yet - it's obvious that it's still much of a work in progress, but that's what Firefox/Thunderbird are called 'preview releases' for. For Mozilla though, that's not much of an excuse. Then again, there's so many software around which doesn't have auto-update features, doesn't make them inherently bad. But, not real 'good' either, 'cause with browsers security is of course an important issue. Fortunately Mozilla is still the minority browser, so I doubt someone will actually exploit this security leak. ~Grauw Note: setting the pref by hand fixes the issue _only_ for the current profile. So it's not a recommended way of fixing this. Use the XPI. Gerv > Use the XPI. How do we install this for all profiles - extensions seem to install themselves in the profile anyway, don't they? Is there something special we need to do, or is this XPI specially configured to install into the program directory? Thanks, Sam I'm using Firefox 0.9.1 on XP and cant get the patch to install. After clicking 'Install Now', the extension manager box appears but does not list shellblock. I've restarted and tried multiple times to no avail. Looks like it needs some work. #26 Re: Re: Setting pref using about:config is not watby AlexBishop Thursday July 8th, 2004 6:15 PM "After clicking 'Install Now', the extension manager box appears but does not list shellblock." It doesn't appear in the Extensions window. Go to http://www.mccanless.us/mozilla/mozilla_bugs.htm to see if you're still vulnerable. Alex Well that is pretty bloody crap. For the average user, or even a power user, it is not immediately apparent that the security fix has been applied. The security fix should be listed in the extension manager. When I go to another system running firefox I should be able to determine at a glance whether the fix has been applied, not follow a convoluted process. Well that is pretty bloody crap. For the average user, or even a power user, it is not immediately apparent that the security fix has been applied. The security fix should be listed in the extension manager. When I go to another system running firefox I should be able to determine at a glance whether the fix has been applied, not follow a convoluted process. Just go to about:config and see if network.protocol-handler.external.shell exists (and is set to false). On http://www.mccanless.us/mozilla/mozilla_bugs.htm the following link still shows (i didn't click it). "The following will accomplish the same as the above by using it as the source of an iframe. Click to show file" I will admit that i just noticed that the XPI update was for Win XP &i'm using an older system than that... but does this mean that i'm still vulnerable? On http://www.mccanless.us/mozilla/mozilla_bugs.htm the following link still shows (i didn't click it). "The following will accomplish the same as the above by using it as the source of an iframe. Click to show file" I will admit that i just noticed that the XPI update was for Win XP &i'm using an older system than that... but does this mean that i'm still vulnerable? I don't understand how to fix this .... :( Do I download 0.7.2 and 0.9.2 of TBird and FFox or do these patches or both? Either will fix the problem but because the fix is just a preference change it's easier to do the xpi installation and just restart the browser rather than have to reinstall the browser. I think they mainly released the new version for people who are going to install the program for the first time. Existing users don't need to go through the hassle just to effectively get a version change when you can get the fix with the xpi. I just decided to finally update from 0.9 to 0.9.1, but much to my surprise, I downloaded 0.9.2 even though the firefox page hasn't been updated yet! I went the route of installing 1.7.1 to resolve the problem. So far, the FTP site has no readme or other document detailing what's in this release. Anyone know if this is the only fix in 1.7.1, or if there is anything else? That's the only fix. 1.7.1 is just 1.7.0 plus the fix and with a version number change. There was work going towards a 1.7.1 with other fixes - that's still ongoing, and will presumably now be called 1.7.2. I thought all they did was add shell: to a blacklist. How do you explain these bizarre file size differences? Mozilla 1.7.1 win32 zip 11,366,599 bytes Mozilla 1.7 win32 zip 11,366,834 bytes -235 bytes (less!) Mozilla 1.7.1 win32 installer-exe 12,042,960 bytes Mozilla 1.7 win32 installer-exe 12,378,832 bytes -335,872 bytes (less!) Firefox 0.9.2 win32 zip 6,317,526 bytes Firefox 0.9.1 win32 zip 6,283,289 bytes 34,237 bytes Firefox 0.9.2 win32 setup-exe 5,078,944 bytes Firefox 0.9.1 win32 setup-exe 4,959,023 bytes 119,921 bytes I just read http://mozilla.org/security/shell.html and noticed, that it doesn't make clear, who is affected by the bug. As I can see from Bugzilla only Windows XP seems to be vulnerable. Could you please add that information to the website? It will be bad enough to read about that in the news, but it would be at least a bit less damaging, when stated, that only Win XP is affected. Regards Abdulkadir Topal I'm using Windows ME. When I tried the links off the mcanless.com test page, "shell:windows" did open my Windows directory. So I guess ME is affected in some way. Like .7 or .8 etc? Thanks. Yes the page below tells what version of mozilla products it works with: http://update.mozilla.org/extensions/moreinfo.php?id=154&vid=261&category=&page=releases "Some may find it notable that a patch was issued less than forty-eight hours after this bug was filed." ... after the problem had been filed in 2002. Selectively leaving out the nasty bits? I'm referring to this bug: http://bugzilla.mozilla.org/show_bug.cgi?id=167475 It seems like that one is the root of all this. "... after the problem had been filed in 2002." There was no known exploit in 2002. A sample exploit was posted to Bugzilla on Wednesday 7th July 2004 at 6:46am Pacific Daylight Time. That's less than forty-eight hours ago. That said, I'm regretting adding the "less than forty-eight hours" part, particularly as I'm now fairly certain it should be "fewer than forty-eight hours". Alex "Less" is a better choice than "fewer" in this case. "Less" is for measurement. "Fewer" is for counting. In this case we're talking about a measure of time, so "less than 48 hours" is correct (at least in American usage). Time is continuous and uncountable so you have "less time"; however, in this case we're talking about hours, which are discrete and countable, so I think it should have been "fewer than forty-eight hours". Alex Looks like CERT has issued an advisory to immediately stop using FireFox and switch to Firebird. I guess this vulnerability requires that IE be installed. On my Win95 (installed with no IE) all I get is a "shell is not a registered protocol". :) Wouldn't systems vulnerable to this also be vulnerable using IE? Is this the preference setting for changing the version # to 0.9.2 after installing the xpi's----> general.useragent.vendorSub? I downloaded 0.9.1 a few days ago, since I have heard about the flurry of security issues with IE. I just got around to installing it yesterday. I liked it. Lots of nifty stuff. I saw the extensions, and thought I'd browse around to see what all was there. Buried at the bottom was a security update(!). This is scarier than Windows. At least Windows tells me that a patch is available, I don't have to dig around. As the proverbial Joe Blow user, I think you need to consider some kind of automatic notification of security patches as a very high priority...if you guys can patch this in 24 hours, how long would it take to make something that checks a secured page at intervals to see if there are any critical issues or updates. Automatic updates might be harder to do, but something like this might do, in the meantime. I could find a patch, if I knew I should be looking for one. Hi, We have an old system and we browse in superparanoid mode, for most part. So we never use Active-X and only use Java as required. So we do not even know what a file with extension .xpi is. Can someone please enlighten us? Also, isn't there some place in WINDOWS SYSTEM files where we can turn off this protocol, so that we are not vulnerable to this "shell" bug? Thanks. Hi again-- Apparently the following will work just as easily as downloading the .xpi file (found this info at CERT.org): Workarounds Disable the shell: protocol handler Mozilla and Firefox users, particularly those who are unable to apply the patches supplied by the Mozilla Project, are encouraged to consider disabling the shell: protocol handler. This can be accomplished by adding the following line to the prefs.js file: user_pref("network.protocol-handler.external.shell", false); Will edit the prefs.js file as described. BUT: Again, I ask: Isn't there somewhere in WINDOWS itself where we can disable this shell: protocol handler? What does the average person use Shell: protocol for? If we do not use TelNet and similar programs, do we need shell? Thanks in advance for any clarification anyone can provide. Hi again, Just found this statement on a webpage at http://www.windowsbbs.com/showthread.php?t=32807: Windows 98 users are not affected by the vulnerability. So all that concern (about how to install the patch to close the security hole) was apparently for nothing!? It would be useful if developers and security experts would remember that some of us 'Dinosaurs' out here still use OLDER programs--and at least mention those systems which are not in jeopardy when they publish these alarming vulnerability reports. Thanks. :-) |