When inserting an iframe into an HTML document with an extension that has a src attribute with a chrome url, the content does not load in Bon Echo, but works in 1.5.0.*

RESOLVED WONTFIX

Status

()

Core
Security
RESOLVED WONTFIX
11 years ago
11 years ago

People

(Reporter: sdwilsh, Assigned: dveditz)

Tracking

({regression, testcase})

Trunk
x86
All
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(9 attachments, 2 obsolete attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060321 Firefox/2.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060321 Firefox/2.0a1

I've written an extension that adds an iframe to a location within an html document, with a source document that is a chrome url that is within the extension.  In 1.5-1.5.0.*, the browser added this without a problem, however with Bon Echo I get this error (with the test case that is soon to be attached):

Security Error: Content at https://bugzilla.mozilla.org/duplicates.cgi?product=Mozilla%20Application%20Suite&product=Firefox&format=simple may not load or link to chrome://testcase/content/test.xul.

Reproducible: Always

Steps to Reproduce:
1. Install test.xpi and restart Firefox.
2. Load any web page.

Actual Results:  
The content of the iframe will not load.

Expected Results:  
The content should load.
(Reporter)

Comment 1

11 years ago
Created attachment 216357 [details]
Test Case

Test case as described in initial description.

Updated

11 years ago
Keywords: regression
Version: unspecified → 2.0 Branch

Updated

11 years ago
Keywords: testcase
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-02-27+03%3A00&maxdate=2006-02-27+12%3A00

Seems like two security bugs are responsible for that.
Apparently regression from bug 327078. Not sure what the extension is doing is sensible, security wise, but I guess it should just work.
Assignee: nobody → dveditz
Blocks: 327078
Status: UNCONFIRMED → NEW
Component: Security → Security
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: firefox → toolkit
Version: 2.0 Branch → Trunk
Created attachment 216403 [details]
extension code

This is basically what the extension is trying to do.

Comment 5

11 years ago
Looks like a regression from 1.8.0.* to 1.8.1
Flags: blocking1.8.1?
What the extension is doing gives content access to a window which has a chrome-privileged document loaded in it, so I very much suspect it's a security hole to start with.

That said, I see no way to get this to work "right" (whatever that means; in this case I mean "like before, for this specific testcase") without compromising security; see the comments the patch for bug 327078 added.

Inserting the iframe and then setting window.location on it from chrome script _might_ work to load the chrome URI.  At least it would pass the CheckLoadURI check....  I still think the result would be exploitable, of course, but I do think that if privileged code is that intent on shooting itself in the foot we should allow it to do so.
In case it wasn't clear, I feel that we should wontfix this.
Also note that the patch for bug 327078 made it into 1.8.0.2 if that matters for our regression-tracking purposes.
(Reporter)

Comment 9

11 years ago
(In reply to comment #6)
> What the extension is doing gives content access to a window which has a
> chrome-privileged document loaded in it, so I very much suspect it's a security
> hole to start with.

I was thinking the same thing today, so I came up with a testcase (soon to be attached).  Attempting to access the iframe that was added by the test extension (Test Case 2 XPI) produces this error:
Error: 'Permission denied to get property XULDocument.getElementById' when calling method: [nsIDOMEventListener::handleEvent] = NS_ERROR_XPC_JS_THREW_STRING

I think this demonstrates that the web page cannot access the privileged content, and so this wouldn't be a security issue.
(Reporter)

Comment 10

11 years ago
Created attachment 216446 [details]
Test Case 2 XPI
(Reporter)

Comment 11

11 years ago
Created attachment 216447 [details]
Test Case 2 HTML
(Reporter)

Comment 12

11 years ago
Created attachment 216448 [details]
Test Case 2 extension code
Just access to privileged objects has caused security issues in the past.  Not privileged DOM nodes -- that's blocked.  Privileged JS objects.
Allowing chrome windows inside content makes me nervous. We might not be able to come up with an exploit today, that doesn't mean that there aren't any, or that some won't sping up tomorrow.

Could you possibly use some other protocol then chrome://? Like res://? Or maybe simply file://? Should we perhaps come up with some new protocol that maps to the same file-paths as chrome but that doesn't imply chome-level access?
(Reporter)

Comment 15

11 years ago
(In reply to comment #14)
> Allowing chrome windows inside content makes me nervous. We might not be able
> to come up with an exploit today, that doesn't mean that there aren't any, or
> that some won't sping up tomorrow.
> 
> Could you possibly use some other protocol then chrome://? Like res://? Or
> maybe simply file://? Should we perhaps come up with some new protocol that
> maps to the same file-paths as chrome but that doesn't imply chome-level
> access?

Regrettably, I know of no other way to do what I've done.  The actual extension is for a specific web site (www.roosterteeth.com) and it adds a rich text editor in place of their current text box with the iframe.  The editor XUL file is 12KB, and the JS file that goes along with it is 25KB.  This really is the main feature of the extension, so this bug kills the whole concept off.

The other problem is that within the editor, I open ChromeWindows to other XUL files that are packaged with the extension as well.
(Reporter)

Comment 16

11 years ago
(In reply to comment #14)
> Should we perhaps come up with some new protocol that
> maps to the same file-paths as chrome but that doesn't imply chome-level
> access?

You know, the more I think about this, the more I like that idea, because the only alternative I can think of is to use file:// paths, but even then I'd would have to figure out where it is in chrome before I could do that.  Things could get even more complicated if the data is in a jar file.  How feasible would this suggestion  be?
I'm pretty sure the resource:// protocol can be made to do what you want, with a directoryservice key to provide the mapping.
(Reporter)

Comment 18

11 years ago
(In reply to comment #17)
> I'm pretty sure the resource:// protocol can be made to do what you want, with
> a directoryservice key to provide the mapping.

Regrettably, that does not work as it throws the same error as trying to access chrome with Test Case 3:
Security Error: Content at http://www.google.com/ may not load or link to resource://gre/res/viewsource.css.

A resource doesn't have any special rights, correct?  Why would this error be occurring?
(Reporter)

Comment 19

11 years ago
Created attachment 216553 [details]
Test Case 3 XPI

Steps to reproduce:
1) Install Test Case 3 XPI
2) Restart browser, and navigate to http://www.google.com/

In 1.5.0.1, it properly loads the resource, but in Bon Echo it throws a security error.
(Reporter)

Comment 20

11 years ago
Created attachment 216554 [details]
Test Case 3 extension code
resource: can only be loaded by chrome: or resource:, per CheckLoadURI.  I do think using resource: there _might_ be safe.  Does doing what I suggested in comment 6 work for loading a resource: URI?
(Reporter)

Comment 22

11 years ago
Created attachment 216753 [details]
Test Case 4 XPI (workaround)

As noted in comment #6, inserting the iframe and then changing its location from chrome does in fact work with both Bon Echo and 1.5.0.1.  Now, isn't this equivalent to what we had before, but it just takes an additional step to accomplish?  I feel as though either this shouldn't work for the same reason as I had to open this bug, or the initial way should work.  I'm leaning more towards the former however, but I'm not sure if that should be filed as a different bug or not.

I should also note that it worked for a resource uri as well, but I haven't been able to find any documentation as to how to set a resource uri to point to some location in chrome (or anywhere for that matter).  I'm not sure if a resource uri would be better from a security standpoint or not either.
(Reporter)

Comment 23

11 years ago
Created attachment 216754 [details]
Test Case 4 extension code
(Reporter)

Comment 24

11 years ago
Created attachment 216755 [details]
Test Case 4 HTML
(Reporter)

Updated

11 years ago
Attachment #216754 - Attachment is obsolete: true
(Reporter)

Comment 25

11 years ago
Comment on attachment 216753 [details]
Test Case 4 XPI (workaround)

I lied about the workaround.  Not sure why I thought it was working, because suddenly it is not.
Attachment #216753 - Attachment is obsolete: true
What doesn't work with the workaround?  Are you running it as chrome?  Running it from Bugzilla will _not_ work, of course.
(Reporter)

Comment 27

11 years ago
(In reply to comment #26)
> What doesn't work with the workaround?  Are you running it as chrome?  Running
> it from Bugzilla will _not_ work, of course.

Sorry, I should have been more specific.  At least for me, downloading Test Case 4 HTML and installing the Test Case 4 XPI (workaround), I get this error:
Security Error: Content at file:///G:/Documents%20and%20Settings/Shawn%20Wilsher/Desktop/test.html may not load or link to chrome://testcase/content/test.xul.

So, my workaround didn't workaround anything.  It also does not work for resource:// uri's.  I must have been testing it on 1.5.0.1 when I thought I was using Bon Echo.

Have any other ideas as to how to get something like this to work?
Well, I just looked at the test case 4 code...  It's not setting window.location; it's still setting the frame "src".  That's not what I suggested in comment 6.
(Reporter)

Comment 29

11 years ago
(In reply to comment #28)
> Well, I just looked at the test case 4 code...  It's not setting
> window.location; it's still setting the frame "src".  That's not what I
> suggested in comment 6.
> 

My apologies, but it has been my experience that window.location changes the entire browser window and points it to that, so chrome://browser/content/browser.xul would go to the address specified.  Is there some other way to do that to just the iframe?
Replace the line

  doc.getElementById('frame').src='chrome://testcase/content/test.xul';

with

  doc.getElementById('frame').contentWindow.location.href =
    'chrome://testcase/content/test.xul';
(Reporter)

Comment 31

11 years ago
Created attachment 216812 [details]
Test Case 4 XPI (workaround)

(In reply to comment #30)
Yup, that did the trick.  This does work with Bon Echo, but the question now is, Is this a security risk?
Again, I suspect that it is, but I can't guarantee it one way or another.

In any case, I think this bug as originally filed is wontfix.  We just don't have a sane enough security context in SetSrc() to make it work "right" (whatever that means) in all cases, so we should do the safe thing.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
Flags: blocking1.8.1?
You need to log in before you can comment on or make changes to this bug.