A chrome function executed by content.setTimeout(chromeFun, ...) or content.addEvenetListener(type, chromeFun, ...) runs on the content JS context. Thus, if the chrome function modifies the content DOM, and a content-registered mutation event listener is called, the listener's scripted caller is the chrome function. This is a similar problem to bug 360529.

There is an exploitable code in nsSessionStore.js. http://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/src/nsSessionStore.js#1927 1927 if (aData.innerHTML) { 1928 aContent.setTimeout( 1929 function(aHTML) { 1930 if (aContent.document.designMode == "on") { 1931 aContent.document.body.innerHTML = aHTML; 1932 } 1933 }, 0, aData.innerHTML); 1934 }

This works in trunk/fx3 on Windows/Linux, and in fx2 on Windows.

This works in fx2 on Windows/Linux.

testcase 1, unsurprisingly, works on mac trunk as well.

Blake, can you look at this for 1.8.1.19/1.9.0.5

In this case, sanitizing innerHTML wouldn't have helped at all.

Comment on attachment 344952 [details] [diff] [review] use the chrome window's setTimeout BTW: |this| is a <xul:browser>, so correctly we'd even rather use > let window = this.ownerDocument.defaultView;

Comment on attachment 344952 [details] [diff] [review] use the chrome window's setTimeout >diff -r 1622ca12ba25 browser/components/sessionstore/src/nsSessionStore.js >+ window.setTimeout(function(aHTML) { >+ if (aContent.document.designMode == "on") >+ aContent.document.body.innerHTML = aData.innerHTML; >+ }, 0); You don't need to take an aHTML parameter anymore. r=mrbkap with that. Thanks.

Does bug 460882 cover the actual core issue as well?

Can you create an automated testcase (but not checkin until after we ship the fix)?

I'll look into writing tests for this bug and bug 459906 once I've got some time (probably next weekend).

(In reply to comment #10) > Does bug 460882 cover the actual core issue as well? No, I'll file a followup on it.

Actually, is it possible to use this event in combination with the exploit from bug 360529 to get around the proper use of XPCNativeWrappers? Sanitation might be the only way to fix that bug for real, if so...

(In reply to comment #13) > No, I'll file a followup on it. That's now bug 461861.

(In reply to comment #14) > Actually, is it possible to use this event in combination with the exploit from > bug 360529 to get around the proper use of XPCNativeWrappers? Yes, the exploit for bug 360529 can use mutation events (see bug 360529 comment #23 and bug 430658).

Whoops, I meant bug 459906.

I've adapted the testcases from these bugs for our browser tests. These fail both without the patches and pass with them.

Comment on attachment 344964 [details] [diff] [review] updated to comment #7 and comment #8 approved for 1.9.0.5 and 1.8.1.19, a=dveditz for release-drivers (please watch tinderbox for the tree to open before landing)

This patch does not apply cleanly to 1.9.0, and I don't know the code enough to make the change myself (code around this block is different, and I'm not sure if that changes the fix).

Shawn: Thanks for the check-in!

Checking in browser/components/sessionstore/src/nsSessionStore.js; new revision: 1.104; previous revision: 1.103 Not sure when this will be able to land on trunk, and I don't have a tree to land it on 1.8.1 (maybe mrbkap can do that since I think he has other patches to land there as well?).

This bug was FIXED in bug 464620 where patches hadn't been checked in already. Tests will land in bug 464620 as well.

Verified for 1.8.1.19 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19pre) Gecko/2008112503 BonEcho/2.0.0.19pre. Verified for 1.9.0.5 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5pre) Gecko/2008112505 GranParadiso/3.0.5pr. Doesn't reproduce in current trunk. Marking as verified.