User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040421 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040421 A security vulnerability exists in MacOS X using a combination of disk images and help: URL's that could allow a malicious web site to execute arbitrary code simply by getting a user to click an affected link or visiting a malicious web page. While the vulnerability is at its source something for Apple to fix in the operating system itself, Mozilla is vulnerable to the issue such that a work-around might be useful. Please see: http://macnn.com/rd.php?id=19430 for more information. Reproducible: Always Steps to Reproduce:
*sigh* don*t we have code to support disabling some external protocols?
This is really the same issue as with MS protocol handlers. Glad to see Apple catching up. ;) user_pref("network.protocol-handler.external.disk", false); (s/disk/help/ if desired, or block both, or whatever makes you happy; I feel we should block both, since I see no reason for those protocols to be launched through a web browser). See http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#439 for the list of protocols we already block. Note that these should probable be in the OS-specific prefs files. Also note that firefox, thunderbird, minimo, sunbird may all want similar changes.
Oh, and I'm not sure it's worth keeping this security-sensitive -- this is a publically known vulnerability in the friggin' OS; we're just working around it....
blocking 1.7 Please keep security-sensitive for now, no need to give people ideas.
Well, the patch is adding those two lines to all the relevant JS files (I feel we should block both protocols, as I said). As for ideas, this is filed based on a public forum thread.... Quite frankly, I think keeping this closed is more self-defeating than anything else (at the moment it's keeping people who may be able to create and test the patch from even SEEING the bug exists).
yeah, you're right bz, confidentiality is pointless. The original link only mentioned Safari but I've since seen public posts mentioning other browsers are vulnerable as well.
Created attachment 148702 [details] [diff] [review] Block disk: and help: protocols (thanks bz) Here's a patch, but I can't test the mac. Firefox and thunderbird should get this patch automagically, bug 224578 switched them to use the GRE all.js
Comment on attachment 148702 [details] [diff] [review] Block disk: and help: protocols (thanks bz) r=dveditz (basically it's bz's patch). Need someone with a Mac to verify we actually honor these prefs there and don't do something mac-specific instead.
Mike, could you test? This change can be applied to a Mozilla install without recompiling or anything -- just edit the all.js file in the install and add those lines...
Comment on attachment 148702 [details] [diff] [review] Block disk: and help: protocols (thanks bz) This should work on the Mac as well since the code that processes these prefs is XP.
I had already added these entries to my profile's prefs.js file which worked. I'm adding it to a CVS build now, but I see no reason it should behave differently.
Comment on attachment 148702 [details] [diff] [review] Block disk: and help: protocols (thanks bz) firstname.lastname@example.org for 1.7 final. /be
Note that the relevant IOService code was added at "2002-10-08 17:54", so it looks like this patch should work for the 1.4 branch too....
Can you go ahead and just put this on the 1.4 branch just in case? Thanks
*** Bug 243873 has been marked as a duplicate of this bug. ***
Checked in to: - MOZILLA_1_4_BRANCH - MOZILLA_1_7_BRANCH - trunk - AVIARY_1_0_20040515_BRANCH Did not check into CAMINO branch because I wasn't sure if they were still on the 0.8 branch after the beta shipped (t-box says trunk). Also not sure that Camino was changed to take advantage of the greprefs consolidation bsmedberg did.
camino is still using the 1.7 branch until 0.8 final is released. i think we're using the pref consolidation that bsmedberg did.
*** Bug 163308 has been marked as a duplicate of this bug. ***
VERIFIED, trunk (05-30) & 1.7 (06-01), Mac OS X 10.3.3 help: url's do not open help viewer disk: no longer opens to some system window ("disk:" returns "internal error" pre-fix). There is a difference in behavior between trunk and branch: trunk gives "protocol is not registered error" branch gives treats as hostname and then does what seems to be domain guessing. I think there have been more fixes to URL bar.
Adding Jon Granrose to CC list to help round up QA resources for verification
Based on http://www.unsanity.com/haxies/pa/whitepaper/ and after talking with pinkerton I added afp: and disks: to the excluded list. Then it got checked in by accident when I checked in bug 240552 before I could ask a wider group. Should I back it out?
this verified for 1.7, so I'm removing the "fixed1.7" keyword.