Closed Bug 950427 (CVE-2014-1483) Opened 7 years ago Closed 7 years ago

caretPositionFromPoint and elementFromPoint leak information about iframe contents via timing information


(Core :: Security, defect)

26 Branch
Not set



Tracking Status
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


(Reporter: mozilla, Assigned: roc)



(Keywords: sec-moderate, Whiteboard: [adv-main27+])


(5 files, 1 obsolete file)

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.
Attached file Updated PoC
Updating PoC to (hopefully) work on bugzilla.
Attachment #8347703 - Attachment is obsolete: true
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)
Attached patch fixSplinter Review
Assignee: nobody → roc
Attachment #8348472 - Flags: review?(matspal)
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.
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]

>+  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+
(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 - 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),, and mochitest-chrome, failure in test_passpointerevents.html,
Attached 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+
Closed: 7 years ago
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
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?
Flags: needinfo?(roc)
Comment on attachment 8349354 [details] [diff] [review]
patch v2

NOTE: This flag is now for security issues only. Please see 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.
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+
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.
Whiteboard: [adv-main27+]
Alias: CVE-2014-1483
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 :-)
Group: core-security
You need to log in before you can comment on or make changes to this bug.