Closed Bug 665369 Opened 14 years ago Closed 14 years ago

iframe type=content-primary in XUL allows access to Components

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: johnjbarton, Unassigned)

References

Details

A security exploit against Firebug has been reported: the Net panel renders .html downloads in an iframe with chrome privilege. The test case is https://fbug.googlecode.com/svn/tests/content/branches/1.8/net/4553/iframeContentPrimary.html We have the fix ready for Firebug 1.8. But the fix for Firebug 1.7 does not work and I don't understand why. In 1.8 the main and side panels are <iframe> elements. I set type=content-primary on both, the exploit is blocked. In 1.7 the main and side panels are <browser> elements. I set type=content-primary and Firebug is broken. Statements like: delete sourceBox.targetedLineNumber; where sourceBox is an HTML element in the main panel document throw permission denied. Why does this cause an exception? So I tried to just set the Net panel's iframe to type=content-primary. Firebug works, but so does the exploit. I verified that the iframe is content-primary this way: var iframe = netInfoBox.getElementsByClassName("netInfoHtmlPreview").item(0); FBTrace.sysout("iframe is type "+iframe.getAttribute('type')); iframe.contentWindow.document.body.innerHTML = text; and I get iframe is type content-primary We need a solution for 1.7 because 1.8 is not ready to all users and because 1.7 is widely deployed.
> Why does this cause an exception? Blake might know.... I have no idea offhand. > So I tried to just set the Net panel's iframe to type=content-primary. In exactly what way? Note that the value of "type" is read when the <iframe> is inserted into the DOM; changing it after that has no effect (at least for your purposes). Does that matter in your situation?
(In reply to comment #0) > In 1.7 the main and side panels are <browser> elements. I set > type=content-primary and Firebug is broken. Statements like: > delete sourceBox.targetedLineNumber; > where sourceBox is an HTML element in the main panel document throw > permission denied. John, I can't reproduce this problem. I have set type="content-primary" in Firebug 1.7.2, run all tests and all seem to be OK. I have also search for "delete sourceBox.targetedLineNumber;" occurrence (just one in sourceBox.js, line 641 and managed to execute it (by clicking on a script link displayed in the the Console panel). Honza
I repeated my tests in a clean profile. The problems with delete I reported do *NOT* appear. If we mark both the browser and its iframe as type="content-primary", then the exploit fails. We can release a patched version of Firebug. However, based on this test, An iframe marked type=content-primary at the time of construction inside of a browser element marked type=chrome allows code in the iframe to exploit the browser. To be sure, the iframe in our case is added with Firebug's domplate system, it may create the element then change its type attribute.
The original exploit link, I did not want to post it on the Firebug issues list which does not have a private viewer setting: http://www.80vul.com/firefox/firebug0day.htm
The problem with the delete seems to be for FF3.6 only, not in FF4.0. It would be a separate bug, but should we bother? Honza suggests disabling the HTML preview feature in Firebug 1.7. I guess we could just disable it for FF3.6+1.7.
(In reply to comment #6) > The problem with the delete seems to be for FF3.6 only, not in FF4.0. It > would be a separate bug, but should we bother? Honza suggests disabling the > HTML preview feature in Firebug 1.7. I guess we could just disable it for > FF3.6+1.7. All the problems I see when running our tests sweet appears when the content-primary attribute is set on <browser> elements in firebugOverlay.xul (Firefox 3.6 + Firebug 1.7 combo only). I don't know how to set the attribute dynamically only for Firefox 3.6... As the comment #1 says, the attribute can't be changed after <iframe> (the same for <browser>) is inserted into DOM. It would have to be done in chrome.manifest before the overlay (firebugOverlay.xul) is applied but, it doesn't seem to be possible. Or I am wrong? Honza
Firebug 1.7.3 + 1.8b4 released http://blog.getfirebug.com/2011/06/20/firebug-1-7-3-firebug-1-8b4/ The affected feature (html preview in the Net panel) is disabled in 1.7.3 since it breaks 1.7.3 + Firefox 3.6 combo. It's properly fixed in 1.8b4 Honza
Blocks: 665418
So what's the state of this bug? Is there a non-domplate testcase showing the problem? Is domplate just doing what I said won't work in comment 1 (in which case domplate is _seriously_ broken performance-wise)? Something else?
Firebug does not depend upon this bug. I believe that domplate setting the attribute via element.attributeName= x in JS. If an iframe does grant privilege unless it is created via markup, this should at least be documented as a security exposure in my opinion. I'm not able to contribute a test case at this time.
> I believe that domplate setting the attribute via element.attributeName= x in > JS. Yes, but does it do that before or after inserting the element in the DOM? > If an iframe does grant privilege unless it is created via markup It doesn't, as long as you set the type before inserting in the DOM. > I'm not able to contribute a test case at this time. In that case this bug is probably incomplete as it stands... not much to go on here, and I can't reproduce with any of the testcases I've tried, and I see nothing about how to reproduce it even using domplate. :(
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
(In reply to comment #11) > > If an iframe does grant privilege unless it is created via markup > > It doesn't, as long as you set the type before inserting in the DOM. I (sorta) fixed the doc page https://developer.mozilla.org/en/XUL/iframe
Group: core-security
You need to log in before you can comment on or make changes to this bug.