Closed Bug 243699 Opened 20 years ago Closed 20 years ago

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

Categories

(Core :: Networking, defect)

PowerPC
macOS
defect
Not set
major

Tracking

()

VERIFIED FIXED

People

(Reporter: mike, Assigned: dveditz)

References

Details

(Keywords: fixed-aviary1.0, fixed1.4.2, verified1.7, Whiteboard: [sg:fix], fixed 1.8a1)

Attachments

(1 file)

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?
Assignee: general → file-handling
Status: UNCONFIRMED → NEW
Component: Browser-General → File Handling
Ever confirmed: true
QA Contact: general → ian
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.
Flags: blocking1.7+
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.
Group: security
Summary: A malicious web site could execute arbitrary code using a disk:// URL and a help:// URL → arbitrary code execution using disk:// and help:// URLs
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
Assignee: file-handling → 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.
Attachment #148702 - Attachment description: Block disk: and help: protocols → Block disk: and help: protocols (thanks bz)
Attachment #148702 - Flags: superreview?(bryner)
Attachment #148702 - Flags: review+
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.
Attachment #148702 - Flags: approval1.7?
Attachment #148702 - Flags: superreview?(bryner) → superreview+
Comment on attachment 148702 [details] [diff] [review]
Block disk: and help: protocols (thanks bz)

a=brendan@mozilla.org for 1.7 final.

/be
Attachment #148702 - Flags: approval1.7? → approval1.7+
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.
Flags: blocking1.8a+
Keywords: fixed1.4, fixed1.7
Whiteboard: fixed ff0.9 (aviary1.0 branch), fixed 1.8a1
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Keywords: fixed1.4fixed1.4.2
Whiteboard: fixed ff0.9 (aviary1.0 branch), fixed 1.8a1 → fixed aviary1.0 branch, fixed 1.8a1
*** 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.
Status: RESOLVED → VERIFIED
Component: File Handling → Networking
Keywords: fixed1.7verified1.7
QA Contact: ian → benc
Keywords: fixed1.7
Whiteboard: fixed aviary1.0 branch, fixed 1.8a1 → fixed-aviary1.0, fixed 1.8a1
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.
Keywords: fixed1.7
Whiteboard: fixed-aviary1.0, fixed 1.8a1 → [sg:fix]fixed-aviary1.0, fixed 1.8a1
Keywords: fixed-aviary1.0
Whiteboard: [sg:fix]fixed-aviary1.0, fixed 1.8a1 → [sg:fix], fixed 1.8a1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: