The default bug view has changed. See this FAQ.
Bug 727303 (CVE-2012-0460)

window.fullScreen can be set by untrusted content but does not check for permission or show escape UI

VERIFIED FIXED in Firefox 11

Status

()

Core
DOM
VERIFIED FIXED
5 years ago
10 months ago

People

(Reporter: mbrubeck, Assigned: cpearce)

Tracking

(Blocks: 1 bug, {regression, testcase})

9 Branch
mozilla13
regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox10 wontfix, firefox11+ verified, firefox12+ verified, firefox13+ verified, firefox-esr1011+ verified, status1.9.2 unaffected)

Details

(Whiteboard: [sg:moderate][qa!], URL)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
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
(Assignee)

Comment 2

5 years ago
Testcase?
(Reporter)

Comment 3

5 years ago
Created attachment 597246 [details]
test case
(Reporter)

Updated

5 years ago
Keywords: testcase
(Assignee)

Comment 4

5 years ago
Oh oops.
status-firefox10: --- → affected
status-firefox11: --- → affected
status-firefox12: --- → affected
tracking-firefox11: --- → ?
(Assignee)

Updated

5 years ago
Assignee: nobody → cpearce
Isn't this a duplicate of bug 391340?
(Reporter)

Comment 6

5 years ago
(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.
status1.9.2: --- → unaffected
status-firefox-esr10: --- → affected
status-firefox13: --- → affected
tracking-firefox-esr10: --- → ?
tracking-firefox11: ? → +
tracking-firefox12: --- → +
tracking-firefox13: --- → +
Whiteboard: [sg:moderate]
(Assignee)

Comment 8

5 years ago
I have a patch in the works for this, just running it through Try now. Should be ready tomorrow...
(Assignee)

Comment 9

5 years ago
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.
Attachment #598117 - Flags: review?(roc)
Attachment #598117 - Flags: review?(roc) → review+
(Assignee)

Comment 10

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/5326871f6961
https://hg.mozilla.org/mozilla-central/rev/5326871f6961
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
(Assignee)

Comment 12

5 years ago
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.
Attachment #598117 - Flags: approval-mozilla-beta?
Attachment #598117 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 13

5 years ago
We'll need this fixed on esr10 as well.
status-firefox13: affected → fixed
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.
Attachment #598117 - Flags: approval-mozilla-beta?
Attachment #598117 - Flags: approval-mozilla-beta+
Attachment #598117 - Flags: approval-mozilla-aurora?
Attachment #598117 - Flags: approval-mozilla-aurora+
(Assignee)

Comment 15

5 years ago
https://hg.mozilla.org/releases/mozilla-beta/rev/52cf2b0c8439
status-firefox12: affected → fixed
(Assignee)

Comment 16

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/58434c395d1c
status-firefox10: affected → wontfix
status-firefox11: affected → fixed
(Reporter)

Updated

5 years ago
Summary: window.fullScreen can be set by untrusted content but does check for permission or show escape UI → window.fullScreen can be set by untrusted content but does not check for permission or show escape UI
Whiteboard: [sg:moderate] → [sg:moderate][qa+]
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.
tracking-firefox-esr10: ? → 11+
(Assignee)

Comment 18

5 years ago
https://hg.mozilla.org/releases/mozilla-esr10/rev/9e182259cc02
status-firefox-esr10: affected → fixed
How does one use the testcase to verify this bug? Loading it Firefox 10.0.3esr just displays a blank page.
Whiteboard: [sg:moderate][qa+] → [sg:moderate][qa?]
(Assignee)

Comment 20

5 years ago
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.
status-firefox-esr10: fixed → verified
Whiteboard: [sg:moderate][qa?] → [sg:moderate][qa+]

Updated

5 years ago
status-firefox11: fixed → verified
Verified on FF 11 Beta 6, FF 12 Aurora, FF 13 Nightly.
Status: RESOLVED → VERIFIED
status-firefox12: fixed → verified
status-firefox13: fixed → verified
Whiteboard: [sg:moderate][qa+] → [sg:moderate]
Whiteboard: [sg:moderate] → [sg:moderate][qa!]
Alias: CVE-2012-0460
(Reporter)

Comment 23

5 years ago
I think this bug can be made public now.  Is this correct?
Group: core-security
Attachment #598117 - Attachment is patch: true
You need to log in before you can comment on or make changes to this bug.