The default bug view has changed. See this FAQ.

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

VERIFIED FIXED

Status

()

Core
Networking
--
major
VERIFIED FIXED
13 years ago
6 years ago

People

(Reporter: Mike Calmus, Assigned: dveditz)

Tracking

({fixed-aviary1.0, fixed1.4.2, verified1.7})

Trunk
PowerPC
Mac OS X
fixed-aviary1.0, fixed1.4.2, verified1.7
Points:
---
Bug Flags:
blocking1.7 +
blocking1.8a1 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix], fixed 1.8a1)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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....
(Assignee)

Comment 4

13 years ago
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).
(Assignee)

Comment 6

13 years ago
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
(Assignee)

Comment 7

13 years ago
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
(Assignee)

Updated

13 years ago
Assignee: file-handling → dveditz
(Assignee)

Comment 8

13 years ago
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 10

13 years ago
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.
(Reporter)

Comment 11

13 years ago
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.
(Assignee)

Updated

13 years ago
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....

Comment 14

13 years ago
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. ***
(Assignee)

Comment 16

13 years ago
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
(Assignee)

Updated

13 years ago
Status: NEW → RESOLVED
Last Resolved: 13 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.
(Assignee)

Updated

13 years ago
Keywords: fixed1.4 → fixed1.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. ***

Comment 19

13 years ago
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.7 → verified1.7
QA Contact: ian → benc

Updated

13 years ago
Keywords: fixed1.7
Whiteboard: fixed aviary1.0 branch, fixed 1.8a1 → fixed-aviary1.0, fixed 1.8a1
(Assignee)

Comment 20

13 years ago
Adding Jon Granrose to CC list to help round up QA resources for verification
(Assignee)

Comment 21

13 years ago
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

13 years ago
this verified for 1.7, so I'm removing the "fixed1.7" keyword.
Keywords: fixed1.7
(Assignee)

Updated

13 years ago
Whiteboard: fixed-aviary1.0, fixed 1.8a1 → [sg:fix]fixed-aviary1.0, fixed 1.8a1

Updated

13 years ago
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.