331807 - 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.*

Status: RESOLVED WONTFIX

(Core :: Security, defect)

Description

[Shawn Wilsher :sdwilsh]

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.

Comment 1

[Shawn Wilsher :sdwilsh]

Attachment: Test Case

Test case as described in initial description.

Comment 2

[Ria Klaassen (not reading all bugmail)]

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.

Comment 3

[Martijn Wargers (dead)]

Apparently regression from bug 327078. Not sure what the extension is doing is sensible, security wise, but I guess it should just work.

Comment 4

[Martijn Wargers (dead)]

Attachment: extension code

This is basically what the extension is trying to do.

Comment 5

[Tim Riley [:timr]]

Looks like a regression from 1.8.0.* to 1.8.1

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

In case it wasn't clear, I feel that we should wontfix this.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Also note that the patch for bug 327078 made it into 1.8.0.2 if that matters for our regression-tracking purposes.

Comment 9

[Shawn Wilsher :sdwilsh]

(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.

Comment 10

[Shawn Wilsher :sdwilsh]

Attachment: Test Case 2 XPI

Comment 11

[Shawn Wilsher :sdwilsh]

Attachment: Test Case 2 HTML

Comment 12

[Shawn Wilsher :sdwilsh]

Attachment: Test Case 2 extension code

Comment 13

[Boris Zbarsky [:bzbarsky]]

Just access to privileged objects has caused security issues in the past.  Not privileged DOM nodes -- that's blocked.  Privileged JS objects.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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?

Comment 15

[Shawn Wilsher :sdwilsh]

(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.

Comment 16

[Shawn Wilsher :sdwilsh]

(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?

Comment 17

[Benjamin Smedberg]

I'm pretty sure the resource:// protocol can be made to do what you want, with a directoryservice key to provide the mapping.

Comment 18

[Shawn Wilsher :sdwilsh]

(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?

Comment 19

[Shawn Wilsher :sdwilsh]

Attachment: 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.

Comment 20

[Shawn Wilsher :sdwilsh]

Attachment: Test Case 3 extension code

Comment 21

[Boris Zbarsky [:bzbarsky]]

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?

Comment 22

[Shawn Wilsher :sdwilsh]

Attachment: 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.

Comment 23

[Shawn Wilsher :sdwilsh]

Attachment: Test Case 4 extension code

Comment 24

[Shawn Wilsher :sdwilsh]

Attachment: Test Case 4 HTML

Comment 25

[Shawn Wilsher :sdwilsh]

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.

Comment 26

[Boris Zbarsky [:bzbarsky]]

What doesn't work with the workaround?  Are you running it as chrome?  Running it from Bugzilla will _not_ work, of course.

Comment 27

[Shawn Wilsher :sdwilsh]

(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?

Comment 28

[Boris Zbarsky [:bzbarsky]]

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.

Comment 29

[Shawn Wilsher :sdwilsh]

(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?

Comment 30

[Boris Zbarsky [:bzbarsky]]

Replace the line

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

with

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

Comment 31

[Shawn Wilsher :sdwilsh]

Attachment: 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?

Comment 32

[Boris Zbarsky [:bzbarsky]]

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.