Before the mozRequestFullscreen API was enabled, window.fullScreen was read-only for untrusted content. Now that the DOM fullscreen API is enabled, window.fullScreen is writeable by untrusted content. This is a side-effect of this patch from bug 545812: https://hg.mozilla.org/mozilla-central/rev/f212867dce42#l8.12 This is dangerous because window.fullScreen does not include mozRequestFullscreen's security mechanisms (e.g. IsHandlingUserInput check, popup notification, escape keys). It could be used in a UI spoofing attack. I think this change was unintentional, and the correct solution is to keep window.fullScreen read-only for untrusted content. Content can use the new DOM fullscreen API instead.

As Martijn pointed out in bug 391340 comment 4, our documentation still says that window.fullScreen is read-only: https://developer.mozilla.org/en/DOM/window.fullScreen

Testcase?

Oh oops.

Isn't this a duplicate of bug 391340?

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #5) > Isn't this a duplicate of bug 391340? At the time bug 391340 was filed, "window.fullScreen=true" would fail silently. The patch there changed it from a silent failure to an exception.

I'm giving this a "moderate" rating because it's mostly spoofing, but this is way too easy to abuse not to fix in Fx11. It's also a DoS because most folks won't know how to get out of fullscreen mode if they don't use it (Esc doesn't work) and will probably have to kill Firefox to get out.

I have a patch in the works for this, just running it through Try now. Should be ready tomorrow...

Re-introduce the trusted-for-write check, but enable it to be bypassed (from non-scriptable code). We need to bypass the security check when SetFullScreen() is called directly from nsIDOMDocument::mozCancelFullScreen(), which is untrusted when called from JS. Note we don't need to bypass the check for Element.mozRequestFullScreen(), since that that runs async, so its call to SetFullScreen() runs with the system principal and is trusted.

Comment on attachment 598117 [details] [diff] [review] Patch v1 [Approval Request Comment] Regression caused by (bug #): 545812 User impact if declined: Script will easily be able to enter fullscreen mode without warnings of entry, making us vulnerable to spoofing. Testing completed (on m-c, etc.): Been on m-c for several days Risk to taking this patch (and alternatives if risky): Small risk of regressions. String changes made by this patch: None.

We'll need this fixed on esr10 as well.

Comment on attachment 598117 [details] [diff] [review] Patch v1 [Triage Comment] This is a good fix to take on Aurora/Beta given the fact that this seems to make spoofing through FS way too easy. Approved - please land on mozilla-beta asap to make it into the fourth FF11 beta.

Tracking for Firefox ESR. Please land on mozilla-esr10 as soon as possible. For more information see https://wiki.mozilla.org/Release_Management/ESR_Landing_Process.

How does one use the testcase to verify this bug? Loading it Firefox 10.0.3esr just displays a blank page.

Just load the URL from the bug's URL field. If the (blank) page doesn't go fullscreen, this bug is fixed; so looks like you can mark this as verified then.

Thanks Chris. Yes, Firefox did not go into fullscreen mode with the testcase. Marking verified for Firefox 10.0.3esr.

Verified on FF 11 Beta 6, FF 12 Aurora, FF 13 Nightly.

I think this bug can be made public now. Is this correct?