Last Comment Bug 243699 - arbitrary code execution using disk:// and help:// URLs
: arbitrary code execution using disk:// and help:// URLs
[sg:fix], fixed 1.8a1
: fixed-aviary1.0, fixed1.4.2, verified1.7
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: PowerPC Mac OS X
: -- major (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
: benc
: Patrick McManus [:mcmanus]
: 163308 243873 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2004-05-15 09:50 PDT by Mike Calmus
Modified: 2011-08-05 22:34 PDT (History)
17 users (show)
dveditz: blocking1.7+
dveditz: blocking1.8a1+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Block disk: and help: protocols (thanks bz) (1.61 KB, patch)
2004-05-17 15:38 PDT, Daniel Veditz [:dveditz]
dveditz: review+
bryner: superreview+
brendan: approval1.7+
Details | Diff | Splinter Review

Description Mike Calmus 2004-05-15 09:50:38 PDT
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: for
more information.

Reproducible: Always
Steps to Reproduce:
Comment 1 Christian :Biesinger (don't email me, ping me on IRC) 2004-05-15 10:07:12 PDT

don*t we have code to support disabling some external protocols?
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2004-05-15 10:28:06 PDT
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 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.
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2004-05-15 10:31:12 PDT
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....
Comment 4 Daniel Veditz [:dveditz] 2004-05-17 13:51:26 PDT
blocking 1.7

Please keep security-sensitive for now, no need to give people ideas.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2004-05-17 14:02:14 PDT
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).
Comment 6 Daniel Veditz [:dveditz] 2004-05-17 14:57:24 PDT
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.
Comment 7 Daniel Veditz [:dveditz] 2004-05-17 15:38:54 PDT
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 8 Daniel Veditz [:dveditz] 2004-05-17 15:42:53 PDT
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.
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2004-05-17 15:46:15 PDT
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 10 Darin Fisher 2004-05-17 15:47:12 PDT
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.
Comment 11 Mike Calmus 2004-05-17 16:03:29 PDT
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 12 Brendan Eich [:brendan] 2004-05-17 17:09:29 PDT
Comment on attachment 148702 [details] [diff] [review]
Block disk: and help: protocols (thanks bz) for 1.7 final.

Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2004-05-17 18:05:01 PDT
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....
Comment 14 Mike Kaply [:mkaply] 2004-05-18 05:24:14 PDT
Can you go ahead and just put this on the 1.4 branch just in case?

Comment 15 Mike Pinkerton (not reading bugmail) 2004-05-18 06:45:41 PDT
*** Bug 243873 has been marked as a duplicate of this bug. ***
Comment 16 Daniel Veditz [:dveditz] 2004-05-19 22:56:01 PDT
Checked in to:
- 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.
Comment 17 Mike Pinkerton (not reading bugmail) 2004-05-20 05:58:06 PDT
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.
Comment 18 Christian :Biesinger (don't email me, ping me on IRC) 2004-05-26 13:00:14 PDT
*** Bug 163308 has been marked as a duplicate of this bug. ***
Comment 19 benc 2004-06-01 19:58:55 PDT
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"

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.
Comment 20 Daniel Veditz [:dveditz] 2004-06-17 13:34:50 PDT
Adding Jon Granrose to CC list to help round up QA resources for verification
Comment 21 Daniel Veditz [:dveditz] 2004-06-18 15:58:40 PDT
Based on 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?
Comment 22 benc 2004-06-18 22:57:43 PDT
this verified for 1.7, so I'm removing the "fixed1.7" keyword.

Note You need to log in before you can comment on or make changes to this bug.