Bug 950427 (CVE-2014-1483)

caretPositionFromPoint and elementFromPoint leak information about iframe contents via timing information

RESOLVED FIXED in Firefox 27

Status

()

RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: mozilla, Assigned: roc)

Tracking

({sec-moderate})

26 Branch
mozilla29
sec-moderate
Points:
---

Firefox Tracking Flags

(firefox26 wontfix, firefox27 verified, firefox28 verified, firefox29 verified, firefox-esr24 wontfix, b2g18 wontfix, b2g-v1.1hd wontfix, b2g-v1.2 fixed, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed)

Details

(Whiteboard: [adv-main27+])

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Steps to reproduce:

1. Create a page containing an iframe with a cross-domain src
2. Run document.elementFromPoint() or document.caretPositionFromPoint() across the iframe
3. View the page with Firefox


Actual results:

The time it takes for a *fromPoint() call to complete is heavily on the element under the point in the iframe. An attacker is able to get an approximate idea of how the iframe's DOM is arranged, as well as whether or not it has a scrollbar based solely on the timing information.


Expected results:

*fromPoint() should do a same-origin check before descending into the iframe's DOM if the src is of a different origin, eliminating the timing issues.
(Reporter)

Comment 1

5 years ago
Posted file Updated PoC
Updating PoC to (hopefully) work on bugzilla.
Attachment #8347703 - Attachment is obsolete: true
(Reporter)

Updated

5 years ago
OS: Windows 7 → All
Hardware: x86_64 → All
Flags: needinfo?(roc)
The PoC doesn't seem to work for me but I believe this can be done.

We don't need to do a cross-origin check, we can just avoid descending into the element.
Flags: needinfo?(roc)
Posted patch fixSplinter Review
Assignee: nobody → roc
Attachment #8348472 - Flags: review?(matspal)
(Reporter)

Comment 4

5 years ago
The results from this issue are highly dependant on load, system specs, quality timing information being available, etc. I get far more consistent results on battery than on AC when using my laptop.

I'm attaching a PoC that more consistently demonstrates the issue across systems of different specs.
(Reporter)

Comment 5

5 years ago
Above: Test iframe
Below: Visualization of timing data leaked on my laptop using elementFromPoint. Black = Relatively fast, White = Relatively slow.
Comment on attachment 8348472 [details] [diff] [review]
fix

>content/base/src/nsDocument.cpp
>+  nsIContent* elem = GetNonanonymousContent(ptFrame);
>+  NS_ASSERTION(elem->OwnerDoc() == this, "Wrong document");
>   if (elem && !elem->IsElement()) {

We need "!elem ||" in the assertion, or remove the null-check in the if-stmt?
(and I'd prefer MOZ_ASSERT b/c otherwise failures tend to be unnoticed/ignored)

>+    nsIContent* node = GetNonanonymousContent(outFrames[i]);
>+    NS_ASSERTION(node->OwnerDoc() == this, "Wrong document");
> 
>     if (node && !node->IsElement() && !node->IsNodeOfType(nsINode::eTEXT)) {

same here

r=mats with that
Attachment #8348472 - Flags: review?(matspal) → review+
(Reporter)

Comment 7

5 years ago
(In reply to Jordan Milne from comment #5)
> Created attachment 8348479 [details]
> Screenshot of leaked timing data
> 
> Above: Test iframe
> Below: Visualization of timing data leaked on my laptop using
> elementFromPoint. Black = Relatively fast, White = Relatively slow.

Now that I think about it, since you can see where line wrapping occurs, one would able to infer a decent amount about the text. Resizing the iframe and watching changes in wrapping behaviour would tell you the number of letters when using monospace fonts, along with likely words when using proportional width fonts.
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/7b90928c4551 - mochitest-4, test_remote_passpointerevents.html timeout and probably a shutdown timeout (it's hard to tell, since we have tons of shutdown timeouts anyway), https://tbpl.mozilla.org/php/getParsedLog.php?id=32139470&tree=Mozilla-Inbound, and mochitest-chrome, failure in test_passpointerevents.html, https://tbpl.mozilla.org/php/getParsedLog.php?id=32139481&tree=Mozilla-Inbound.
Posted patch patch v2Splinter Review
The previous patch indeed broke passpointerevents quite badly. This fixes it. passpointerevents can only be used by privileged code so it doesn't lead to any timing attacks. (It already leads to other kinds of information exposure about the subdocument.)

I also patched caretPositionFromPoint here.
Attachment #8349354 - Flags: review?(matspal)
Comment on attachment 8349354 [details] [diff] [review]
patch v2

> I also patched caretPositionFromPoint here.

I should have caught that in the last review, sorry about that.
Attachment #8349354 - Flags: review?(matspal) → review+
https://hg.mozilla.org/mozilla-central/rev/cdbe5779c728
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
status-firefox29: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Duplicate of this bug: 950423
What security rating should this get?  Is this trunk only, or does it affect other branches?
Flags: needinfo?(matspal)
I would say sec-low to moderate because the leak is quite coarse.
I would expect all branches to be affected.
Flags: needinfo?(matspal)
Keywords: sec-moderate
status-firefox26: --- → wontfix
status-firefox27: --- → affected
status-firefox28: --- → affected
status-b2g18: --- → affected
status-b2g-v1.1hd: --- → affected
status-b2g-v1.2: --- → affected
status-firefox-esr24: --- → wontfix
This applies with just some minor fuzz to Aurora, Beta, and b2g26. Looks like b2g18 will need a branch-specific patch (if this is even worth fixing there). Roc, can you request approval for the other 3 branches and comment on whether a b2g18 patch is worth making?
status-b2g-v1.3: --- → affected
status-b2g-v1.4: --- → fixed
Flags: needinfo?(roc)
Comment on attachment 8349354 [details] [diff] [review]
patch v2

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): None
User impact if declined: potential cross-origin information leak
Testing completed: Landed on trunk for a while
Risk to taking this patch (and alternatives if risky): low risk
String or UUID changes made by this patch: none

I don't think a b2g18 fix is needed. This is low priority.
Attachment #8349354 - Flags: approval-mozilla-beta?
Attachment #8349354 - Flags: approval-mozilla-b2g26?
Attachment #8349354 - Flags: approval-mozilla-aurora?
Flags: needinfo?(roc)
This is a sec-moderate and a decent sized patch. I'm not sure whether we want to take this on Beta but I'll let release management decide.
status-b2g18: affected → wontfix
status-b2g-v1.1hd: affected → wontfix
Comment on attachment 8349354 [details] [diff] [review]
patch v2

It's being rated as low risk and we've still got a few betas to go so let's get this into tomorrow's build and get the most bake time.
Attachment #8349354 - Flags: approval-mozilla-beta?
Attachment #8349354 - Flags: approval-mozilla-beta+
Attachment #8349354 - Flags: approval-mozilla-b2g26?
Attachment #8349354 - Flags: approval-mozilla-b2g26+
Attachment #8349354 - Flags: approval-mozilla-aurora?
Attachment #8349354 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/3d50d3496a64
https://hg.mozilla.org/releases/mozilla-beta/rev/ecaeefa36a03
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/8fdb22a99151
status-b2g-v1.2: affected → fixed
status-b2g-v1.3: affected → fixed
status-firefox27: affected → fixed
status-firefox28: affected → fixed
Matt is this something you can verify?
Flags: needinfo?(mwobensmith)
Keywords: verifyme
Yes, I will give it a go, thanks.
Flags: needinfo?(mwobensmith)
QA Contact: mwobensmith
Confirmed bug on FF27 beta, 2014-01-15.
Verified fixed on FF27, FF28 and FF29, 2014-01-17.
status-firefox27: fixed → verified
status-firefox28: fixed → verified
status-firefox29: fixed → verified
Keywords: verifyme
Whiteboard: [adv-main27+]
Alias: CVE-2014-1483
(Reporter)

Comment 25

5 years ago
Following up on Boris' comment in duped Bug 950423, should spec issues be raised about the cross-doc behaviour of document.*FromPoint()? The CSSOM View Module doesn't seem to mention any restrictions on them or their hit testing functions, and says that hit testing isn't specified.
Yes, the spec is a little unclear on this issue. Please feel free to raise a spec issue :-)
status-b2g-v1.3T: --- → fixed
Group: core-security
You need to log in before you can comment on or make changes to this bug.