404822 - [Frame] Assessing TOP window object from a frame throws permission denied message for "file://" protocol

Status: RESOLVED INCOMPLETE

(Firefox :: Security, defect)

Description

[Eric Lim]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1

From a frame page, I get a permission denied message when I try to access the TOP window object.

Reproducible: Always

Steps to Reproduce:
1. Load the attached testcase.html

Actual Results:  
Nothing is shown

Expected Results:  
Show see "Success" in the left frame.

Is this related to bug 255667 and 385619?

This was broken in alpha build 8 of Grand Paradiso, when the malware protection was introduced.

This testcase works in Firefox 2, IE 6&7, Opera 9.24, and Safari 3.

Comment 1

[Eric Lim]

Attachment: main page

Comment 2

[Eric Lim]

Attachment: frame page with javascript code

Put attached file to "testcase_files" directory.

testcase.html
testcase_files\frame1.html

Comment 3

[Eric Lim]

I can not think of a work around.  If anyone has one, then please let me know.

Comment 4

[Eric Lim]

This security issues only occurs when I access "testcase.html" with the "file://" protocol.  When I access "testcase.html" with the "http://" protocol, firefox load the page without a problem.

Comment 5

[Eric Lim]

Related to bug 230606 and bug 404678

Comment 6

[Eric Lim]

Here is the scenario:

1.  The FRAMESET file lives in <dir1>/frameset.html
2.  The FRAME files lives in <dir1>/<dir2>/frame1.html
3.  When we access the TOP window object from the FRAME files, we are accessing the FRAMESET file that lives one directory down.  By default, the file:// protection only allow access to itself, all files in its directory, and all subdirectories.  

I believe this protection should start from the FRAMESET file, not the FRAME files.

Comment 7

[Brian Polidoro]

I checked the regression range which fits bug 230606: 
20070905 ok
20070906 broke

Comment 10

[Brian Polidoro]

Some discussion on this is in Bug 402983 starting with Bug 402983 comment #10.

Comment 11

[Daniel Veditz [:dveditz]]

We are making some changes here (for bug 402983) but they are not going to completely satisfy you, at least not as described in comment 6 (comment 2 should work, though). Historically it has been convenient to develop on a local file system, but for the average user this has been a security disaster as multiple hacks over the past couple of years have shown.

Microsoft's approach is to restrict the running of script entirely, but if you do allow script to run then it has all the same potential problems.

We're trying an alternate approach--which may well fail--of restricting access while allowing at least self-contained pages to run useful scripts. People who are developing using local files as a temporary substitute for a webserver can easily relax the restrictions for their own use while leaving the vast majority of users protected. If the files are intended to be deployed _as_ files then you're probably out of luck. There is no safe way to use your file set while being protected against rogue files from the internet.

Comment 12

[Tom Nowacki]

I'm joining this from another duplicate bug posted. (see https://bugzilla.mozilla.org/show_bug.cgi?id=414283)

Is what your are saying that:

"Document A in frame 1 in local subfolder is denied permission to get object
properties and run scripts in document B in frame 2 in local parent folder"

has been finalized?

I'd rather know sooner than later, because I have files intended to be deployed locally. I can change the folders, so the files are all in the same root.

Comment 13

[Daniel Veditz [:dveditz]]

The current intention, which may change if it proves unworkable, is to make "save webpages complete" work by allowing test.html and test_files/something.html able to access each other. But not an arbitrary number of levels deep or it turns out any "symmetric" checks would allow an attacker to still read the whole disk.

Comment 14

[Tom Nowacki]

The problem is getting worse.

Document A in frame 1 in local folder is denied permission to get object 
properties and run scripts in document B in frame 2 in local folder.

When the files are both in the root directory having them in different frames causes the error. This will not do. You are prevented from using frames offline if that happens.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032505 Minefield/3.0b5pre - Nightly build: 25 March.

Comment 15

[Tom Nowacki]

Attachment: example of plugin that can't be embedded

Here's another permutation. I'm pretty sure it boils down to the same bug:

When you open a frameset in an adjacent local folder in a new window, the frames don't embed plugins.

Comment 16

[Tom Nowacki]

Restricting access to local files not in the root is understandable. There have been security issues surrounding local files and you can work around the restriction if you're deploying by placing your files in the same folder. What I don't understand is the restriction on scripting across frames. Why does that help in security terms, if that is the intention? Am I drawing the wrong conclusion? It might be another bug. Will Firefox 3 be compatible with frames that have scripts offline? 

Comment 17

[Jonathan Huestis]

(In reply to comment #14)
> The problem is getting worse.
> 
> Document A in frame 1 in local folder is denied permission to get object 
> properties and run scripts in document B in frame 2 in local folder.
> 
> When the files are both in the root directory having them in different frames
> causes the error. This will not do. You are prevented from using frames offline
> if that happens.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032505
> Minefield/3.0b5pre - Nightly build: 25 March.
> 

I've noticed the problem getting worse as well. I've modified other about:config settings for my application to get around security issues like this in the past. For example, in one of the earlier betas I had to start setting security.fileuri.origin_policy=4 to get around related issues.  In Firefox 3 beta5 and RC1, this is no longer sufficient on Windows (though it still seems to work on Linux, at least that's what my test team tells me).  

Is there a setting in about:config that can be modified to allow scripting across frames for local files? Thanks for your help.

Comment 18

[Tom Nowacki]

To get around the FF3 local security setting, I ended up changing grepref/all.js:

pref("security.fileuri.strict_origin_policy", false);

Needless to say, distributing offline content to be viewed in the user's default browser, of necessity has to work without frames now, unless you want to tell everyone opening your html files to make the above change in Firefox 3. I'm not at all happy.

Comment 19

[Jonathan Huestis]

(In reply to comment #18)
> To get around the FF3 local security setting, I ended up changing
> grepref/all.js:
> 
> pref("security.fileuri.strict_origin_policy", false);
> 
> Needless to say, distributing offline content to be viewed in the user's
> default browser, of necessity has to work without frames now, unless you want
> to tell everyone opening your html files to make the above change in Firefox 3.
> I'm not at all happy.
> 

That was exactly what I needed to know, thanks! (Somehow I managed to overlook that the name of the preference changed)

BTW, if we weren't already creating a hacked profile on the fly, this would be a significant problem for our application. I can see this being a problem for a lot of other local HTML based apps out there that don't happen to have a bootstrap routine like we do; the vast majority of existing local web apps expect you to simply open an HTML file to run them, and I'm confident that a good many of those depend on communication between frames.

Comment 21

[u279076]

Resolving unconfirmed bugs older than a year with no activity as INCOMPLETE.  Please reopen or file a new bug if you can still reproduce the bug.