135830 - [RFE] Allow graded access to file:// links within mailnews

Status: RESOLVED WONTFIX

(MailNews Core :: Security, enhancement)

Description

[Ian Neal]

Using buildid 2002040210 on Windows XP
Reproducible: Always

Steps to Reproduce
1. Get someone using N.4x to email you a link to a file on a shared network drive.
2. Try clicking on link

Actual Result.
Clicking on link does nothing

Expected Result:
Clicking on link opens file from shared network drive.

Comment 1

[Ian Neal]

This works fine in NS4.x so I'll mark as 4xp

Comment 2

[Boris Zbarsky [:bzbarsky]]

Invalid.  Remote content cannot link to local content for security reasons.  
Mail is remote content.

See bug 84128 for discussion on the issue as well as the pref you can set to 
disable this security check (in bug 84128, comment 20)

Comment 3

[Ian Neal]

Bug 84128 is to do with browser file:// links and whether it pops up a window
and what sort of window it should pop up. This is a change in behaviour from
NS4.x and users, used to NS4.x, will be confused by the change and lack of
explanation. Corporates tend to encourage use of links to files on shared
network drives rather than sending huge attachments round and eating up disk space.

A file:// link in an email doesn't pop up any sort of window error or dialog!

The user_pref("security.checkloaduri", false) mentioned seems to be to black and
white, there should be some sort of grading. I think the Mozilla should be able
to determine whether it is an internal e-mail (or a list of safe domains which
it auto-fills with your domain when you run mail account wizard) or an external
e-mail (or those not in your list of safe domains) and have preferences to let
you configure what Mozilla does with file links in each circumstance.

Reopening and tweaking summary.

Comment 4

[Ian Neal]

Splitting no information pop-up part of bug into bug 157885. I'll alter this bug
to be an enhancement request.

Comment 5

[Ian Neal]

Adjusting summary original summary was "file:// links sent from NS4.x do not
open in Mozilla or pop up an explaination"

Comment 6

[Ian Neal]

Changing dependency to bug 157885 was duped against

Comment 7

[Jean-Francois Ducarroz]

Raising security to normal, the user should be able to click on a valid file url
link. Also set component to Security:General

Comment 8

[Jean-Francois Ducarroz]

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

Comment 9

[Jean-Francois Ducarroz]

Any status on this bug?

Comment 10

[Stefan Borggraefe]

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

Comment 11

[Ian Neal]

Bug 233108 covers the more general case and has a patch.

*** This bug has been marked as a duplicate of 233108 ***

Comment 12

[Boris Zbarsky [:bzbarsky]]

This is different, imo... That bug's patch will let you give your mail messages
access to all files on your hard drive.  Doing so, imo, is stupid.  We need a
better setup for mail messages.

Comment 13

[Mike Cowperthwaite]

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

Comment 14

[Elmar Ludwig]

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

Comment 15

[Mike Cowperthwaite]

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

Comment 16

[Ian Neal]

The first part of a fix to this bug is probably implementing a way of checking if the file resides on a networked drive. AFAIK in non-windows environments this will be any link starting with file://///, in windows there is that but also networked drives which we should be able to determine using a call to GetDriveType

Comment 17

[Daniel B.]

Suggestion: Track security level of operations requesting opening URL, modeling
after the Java privileged block API.

Hey, would the following idea address both sides of the 
problem (preventing arbitrary pages from requesting file:... 
URLs while allowing the user to request them)?


Java Privileged Block API

In Java, when some action requiring special priviledges is 
requested, the VM (effectively) scans the call stack back to 
some higher-privileged reference point and finds the lowest 
privilege level of all pending methods on the stack.  That 
privilege level is used to attempt the operation.

(For example:  A browser's general applet support code has 
privilege to open arbitrary connections.  When it loads an
applet's code, it gives the applet code privilege only to 
open connections to one host.  The socket-connection method 
checks the privilege of the call stack to decide whether to 
allow a connection. 

If the browser calls the connection method, the call stack 
has full privileges and any connection can be opened.  

When the browser invokes the applet, if the applet calls the 
connection method, the call stack has only limited privileges, 
and only certain connections may be opened.

Note that if the applet calls some miscellaneous support code 
in the browser and that code calls the connection method, 
the call stack _still_ has only limited privileges, because 
the stack contains one or more stack frames from the applet.

(There's also a way for browser code called from the applet to
regain higher-level privileges if needs them to perform some
action for the applet.)

)

For more information on this Java mechanism see 
http://java.sun.com/j2se/1.5.0/docs/guide/security/doprivileged.html .


Applying To Mozilla/Seamonkey/Firefox

It seems that that kind of mechanism would be applicable to
Mozilla.

The equivalent of the call stack would be a chain of actions
starting with a user input action (e.g., activating a link), 
going through various handling actions (e.g., invoking untrusted
Javascript), and extending down to each of the possibly multiple 
URL-loading actions indirectly triggered by the user input action.

Generally, user input actions (clicking on a button or link,
or entering a URL directly) would reset the privileges to 
the highest level. 

Handling actions would reduce the privilege level appropriately,
especially for actions that invoke or otherwise "listen to" 
untrusted code or data.

Consider several scenarios:

If the user clicks on a plain (non-Javascript) link, handling 
that click proceeds directly to trying to load the URL.  Since 
user actionshave full privileges, and there are no intervening 
handling steps that reduce the privileges, any URL can be loaded.

If the user clicks on a javascript: link, privileges are decreased
before executing the script, so that if execution of the script 
then tries to load a URL, the URL load is attempted only with the 
reduced privileges allowed for scripts (probably also according 
to the source of the page containing the script), and some URLs 
might not be loadable.

Similarly, the action of executing a script in a loaded page is 
a nested or chained action that has reduced privileges, as is
loading images in a page.


I think a model/mechanism like this could go a long way toward
making Mozilla rationale (not refusing to load file:.. URLs
directly requested by users) while allowing for security
concerns to be addressed.


Comments?

Comment 18

[Kai Engert [:KaiE:]]

I don't think this is a useful way to share resources in local environments. file links on network shares are often local to a specific user, as the user often decides how to name the network share. And there are potential issues, such as misleading a user, or maybe even accidentally including the contents of a local file in a reply (if e.g. the content of the file is loaded into the body of an email using a html tag).

It seems correct not to support file:// links.

We could consider to give better feedback to the user whenever a link is clicked that we chose to ignore, but that should probably be handled in a separate bug report.