243699 - arbitrary code execution using disk:// and help:// URLs

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[Mike Calmus]

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:

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

*sigh*

don*t we have code to support disabling some external protocols?

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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]]

blocking 1.7

Please keep security-sensitive for now, no need to give people ideas.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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]]

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]]

Attachment: 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]]

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 [:bzbarsky]]

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]

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]

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]]

Comment on attachment 148702 [details] [diff] [review]
Block disk: and help: protocols (thanks bz)

a=[e-mail] for 1.7 final.

/be

Comment 13

[Boris Zbarsky [:bzbarsky]]

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]]

Can you go ahead and just put this on the 1.4 branch just in case?

Thanks

Comment 15

[Mike Pinkerton (not reading bugmail)]

*** Bug 243873 has been marked as a duplicate of this bug. ***

Comment 16

[Daniel Veditz [:dveditz]]

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.

Comment 17

[Mike Pinkerton (not reading bugmail)]

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)]

*** Bug 163308 has been marked as a duplicate of this bug. ***

Comment 19

[benc]

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.

Comment 20

[Daniel Veditz [:dveditz]]

Adding Jon Granrose to CC list to help round up QA resources for verification

Comment 21

[Daniel Veditz [:dveditz]]

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?

Comment 22

[benc]

this verified for 1.7, so I'm removing the "fixed1.7" keyword.