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
(CVE-2012-0460)
: window.fullScreen can be set by untrusted content but does not check for perm...
Status: VERIFIED FIXED
[sg:moderate][qa!]
: 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]
Mentors:
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:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix
+
verified
+
verified
+
verified
11+
verified
unaffected


Attachments
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 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:
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.
Comment 1 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:
https://developer.mozilla.org/en/DOM/window.fullScreen
Comment 2 Chris Pearce (:cpearce) 2012-02-14 16:52:42 PST
Testcase?
Comment 3 Matt Brubeck (:mbrubeck) 2012-02-14 16:54:26 PST
Created attachment 597246 [details]
test case
Comment 4 Chris Pearce (:cpearce) 2012-02-14 17:21:38 PST
Oh oops.
Comment 5 Martijn Wargers [:mwargers] (not working for Mozilla) 2012-02-15 02:36:43 PST
Isn't this a duplicate of bug 391340?
Comment 6 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 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 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 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 Ed Morley [:emorley] 2012-02-20 10:21:40 PST
https://hg.mozilla.org/mozilla-central/rev/5326871f6961
Comment 12 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 Chris Pearce (:cpearce) 2012-02-21 12:54:05 PST
We'll need this fixed on esr10 as well.
Comment 14 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 Chris Pearce (:cpearce) 2012-02-21 15:18:36 PST
https://hg.mozilla.org/releases/mozilla-beta/rev/52cf2b0c8439
Comment 16 Chris Pearce (:cpearce) 2012-02-21 15:20:08 PST
https://hg.mozilla.org/releases/mozilla-aurora/rev/58434c395d1c
Comment 17 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 https://wiki.mozilla.org/Release_Management/ESR_Landing_Process.
Comment 18 Chris Pearce (:cpearce) 2012-02-22 16:25:35 PST
https://hg.mozilla.org/releases/mozilla-esr10/rev/9e182259cc02
Comment 19 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 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 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 Jason Smith [:jsmith] 2012-03-06 20:42:55 PST
Verified on FF 11 Beta 6, FF 12 Aurora, FF 13 Nightly.
Comment 23 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.