Last Comment Bug 727303 - (CVE-2012-0460) window.fullScreen can be set by untrusted content but does not check for permission or show escape UI
: window.fullScreen can be set by untrusted content but does not check for perm...
: regression, testcase
Product: Core
Classification: Components
Component: DOM (show other bugs)
: 9 Branch
: All All
-- normal (vote)
: mozilla13
Assigned To: Chris Pearce (:cpearce)
: Andrew Overholt [:overholt]
data:text/html,<body onload="window.f...
Depends on:
Blocks: 391340 545812 726873
  Show dependency treegraph
Reported: 2012-02-14 16:43 PST by Matt Brubeck (:mbrubeck)
Modified: 2016-06-02 06:44 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

test case (39 bytes, text/html)
2012-02-14 16:54 PST, Matt Brubeck (:mbrubeck)
no flags Details
Patch v1 (5.88 KB, patch)
2012-02-16 20:22 PST, Chris Pearce (:cpearce)
roc: review+
akeybl: approval‑mozilla‑aurora+
akeybl: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description User image Matt Brubeck (:mbrubeck) 2012-02-14 16:43:22 PST
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:

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.
Comment 1 User image Matt Brubeck (:mbrubeck) 2012-02-14 16:49:13 PST
As Martijn pointed out in bug 391340 comment 4, our documentation still says that window.fullScreen is read-only:
Comment 2 User image Chris Pearce (:cpearce) 2012-02-14 16:52:42 PST
Comment 3 User image Matt Brubeck (:mbrubeck) 2012-02-14 16:54:26 PST
Created attachment 597246 [details]
test case
Comment 4 User image Chris Pearce (:cpearce) 2012-02-14 17:21:38 PST
Oh oops.
Comment 5 User image Martijn Wargers [:mwargers] 2012-02-15 02:36:43 PST
Isn't this a duplicate of bug 391340?
Comment 6 User image Matt Brubeck (:mbrubeck) 2012-02-15 08:54:42 PST
(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.
Comment 7 User image Daniel Veditz [:dveditz] 2012-02-15 21:04:57 PST
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.
Comment 8 User image Chris Pearce (:cpearce) 2012-02-15 22:43:35 PST
I have a patch in the works for this, just running it through Try now. Should be ready tomorrow...
Comment 9 User image Chris Pearce (:cpearce) 2012-02-16 20:22:00 PST
Created attachment 598117 [details] [diff] [review]
Patch v1

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 11 User image Ed Morley [:emorley] 2012-02-20 10:21:40 PST
Comment 12 User image Chris Pearce (:cpearce) 2012-02-21 12:50:47 PST
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.
Comment 13 User image Chris Pearce (:cpearce) 2012-02-21 12:54:05 PST
We'll need this fixed on esr10 as well.
Comment 14 User image Alex Keybl [:akeybl] 2012-02-21 14:52:37 PST
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.
Comment 15 User image Chris Pearce (:cpearce) 2012-02-21 15:18:36 PST
Comment 16 User image Chris Pearce (:cpearce) 2012-02-21 15:20:08 PST
Comment 17 User image Alex Keybl [:akeybl] 2012-02-22 15:57:29 PST
Tracking for Firefox ESR. Please land on mozilla-esr10 as soon as possible. For more information see
Comment 18 User image Chris Pearce (:cpearce) 2012-02-22 16:25:35 PST
Comment 19 User image Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-03-05 10:58:24 PST
How does one use the testcase to verify this bug? Loading it Firefox 10.0.3esr just displays a blank page.
Comment 20 User image Chris Pearce (:cpearce) 2012-03-05 13:03:16 PST
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.
Comment 21 User image Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-03-05 13:07:13 PST
Thanks Chris. Yes, Firefox did not go into fullscreen mode with the testcase. Marking verified for Firefox 10.0.3esr.
Comment 22 User image Jason Smith [:jsmith] 2012-03-06 20:42:55 PST
Verified on FF 11 Beta 6, FF 12 Aurora, FF 13 Nightly.
Comment 23 User image Matt Brubeck (:mbrubeck) 2012-03-30 14:53:28 PDT
I think this bug can be made public now.  Is this correct?

Note You need to log in before you can comment on or make changes to this bug.