950427 - (CVE-2014-1483) caretPositionFromPoint and elementFromPoint leak information about iframe contents via timing information

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[Jordan Milne]

Attachment: PoC demonstrating cross-origin DOM structure sniffing using *fromPoint().

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.

Comment 1

[Jordan Milne]

Attachment: Updated PoC

Updating PoC to (hopefully) work on bugzilla.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

Comment 4

[Jordan Milne]

Attachment: Visualization of average call time for points inside an iframe

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.

Comment 5

[Jordan Milne]

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

Comment 6

[Mats Palmgren (inactive)]

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

Comment 7

[Jordan Milne]

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

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f55504b0184f

Thanks. This is a rather cool attack.

Comment 9

[Phil Ringnalda (:philor)]

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.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: patch v2

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.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://tbpl.mozilla.org/?tree=Try&rev=8d2d603c698b

Comment 12

[Mats Palmgren (inactive)]

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.

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/cdbe5779c728

Comment 15

[Andrew McCreight [:mccr8]]

What security rating should this get?  Is this trunk only, or does it affect other branches?

Comment 16

[Mats Palmgren (inactive)]

I would say sec-low to moderate because the leak is quite coarse.
I would expect all branches to be affected.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

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?

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 19

[Al Billings [:abillings - ex-MoCo]]

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 20

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

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

Comment 22

[u279076]

Matt is this something you can verify?

Comment 23

[Matt Wobensmith [:mwobensmith][:matt:]]

Yes, I will give it a go, thanks.

Comment 24

[Matt Wobensmith [:mwobensmith][:matt:]]

Confirmed bug on FF27 beta, 2014-01-15.
Verified fixed on FF27, FF28 and FF29, 2014-01-17.

Comment 25

[Jordan Milne]

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.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, the spec is a little unclear on this issue. Please feel free to raise a spec issue :-)