727303 - (CVE-2012-0460) window.fullScreen can be set by untrusted content but does not check for permission or show escape UI

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Matt Brubeck (:mbrubeck)]

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)]

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 (Not reading bugmail)]]

Testcase?

Comment 3

[Matt Brubeck (:mbrubeck)]

Attachment: test case

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

Oh oops.

Comment 5

[Martijn Wargers (dead)]

Isn't this a duplicate of bug 391340?

Comment 6

[Matt Brubeck (:mbrubeck)]

(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]]

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 (Not reading bugmail)]]

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

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: 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 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5326871f6961

Comment 11

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/5326871f6961

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

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 (Not reading bugmail)]]

We'll need this fixed on esr10 as well.

Comment 14

[Alex Keybl [:akeybl]]

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 (Not reading bugmail)]]

https://hg.mozilla.org/releases/mozilla-beta/rev/52cf2b0c8439

Comment 16

[Chris Pearce [:cpearce (Not reading bugmail)]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/58434c395d1c

Comment 17

[Alex Keybl [:akeybl]]

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 (Not reading bugmail)]]

https://hg.mozilla.org/releases/mozilla-esr10/rev/9e182259cc02

Comment 19

[u279076]

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 (Not reading bugmail)]]

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

[u279076]

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]]

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

Comment 23

[Matt Brubeck (:mbrubeck)]

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