Closed
Bug 950427
(CVE-2014-1483)
Opened 11 years ago
Closed 11 years ago
caretPositionFromPoint and elementFromPoint leak information about iframe contents via timing information
Categories
(Core :: Security, defect)
Tracking
()
RESOLVED
FIXED
mozilla29
People
(Reporter: mozilla, Assigned: roc)
References
Details
(Keywords: sec-moderate, Whiteboard: [adv-main27+])
Attachments
(5 files, 1 obsolete file)
1.78 KB,
text/html
|
Details | |
11.18 KB,
patch
|
MatsPalmgren_bugz
:
review+
|
Details | Diff | Splinter Review |
4.28 KB,
text/html
|
Details | |
48.34 KB,
image/png
|
Details | |
10.23 KB,
patch
|
MatsPalmgren_bugz
:
review+
lsblakk
:
approval-mozilla-aurora+
lsblakk
:
approval-mozilla-beta+
lsblakk
:
approval-mozilla-b2g26+
|
Details | Diff | Splinter Review |
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•11 years ago
|
||
Updating PoC to (hopefully) work on bugzilla.
Attachment #8347703 -
Attachment is obsolete: true
Reporter | ||
Updated•11 years ago
|
OS: Windows 7 → All
Hardware: x86_64 → All
![]() |
||
Updated•11 years ago
|
Flags: needinfo?(roc)
Assignee | ||
Comment 2•11 years ago
|
||
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)
Assignee | ||
Comment 3•11 years ago
|
||
Assignee: nobody → roc
Attachment #8348472 -
Flags: review?(matspal)
Reporter | ||
Comment 4•11 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•11 years ago
|
||
Above: Test iframe
Below: Visualization of timing data leaked on my laptop using elementFromPoint. Black = Relatively fast, White = Relatively slow.
Comment 6•11 years ago
|
||
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•11 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.
Assignee | ||
Comment 8•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/f55504b0184f
Thanks. This is a rather cool attack.
Comment 9•11 years ago
|
||
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.
Assignee | ||
Comment 10•11 years ago
|
||
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)
Assignee | ||
Comment 11•11 years ago
|
||
Comment 12•11 years ago
|
||
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+
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
status-firefox29:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Comment 15•11 years ago
|
||
What security rating should this get? Is this trunk only, or does it affect other branches?
Updated•11 years ago
|
Flags: needinfo?(matspal)
Comment 16•11 years ago
|
||
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
Updated•11 years ago
|
Updated•11 years ago
|
status-b2g18:
--- → affected
status-b2g-v1.1hd:
--- → affected
status-b2g-v1.2:
--- → affected
status-firefox-esr24:
--- → wontfix
Comment 17•11 years ago
|
||
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
Updated•11 years ago
|
Flags: needinfo?(roc)
Assignee | ||
Comment 18•11 years ago
|
||
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)
Comment 19•11 years ago
|
||
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.
Updated•11 years ago
|
Comment 20•11 years ago
|
||
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+
Comment 21•11 years ago
|
||
Comment 22•11 years ago
|
||
Matt is this something you can verify?
Flags: needinfo?(mwobensmith)
Keywords: verifyme
Comment 24•11 years ago
|
||
Confirmed bug on FF27 beta, 2014-01-15.
Verified fixed on FF27, FF28 and FF29, 2014-01-17.
Updated•11 years ago
|
Whiteboard: [adv-main27+]
Updated•11 years ago
|
Alias: CVE-2014-1483
Reporter | ||
Comment 25•11 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.
Assignee | ||
Comment 26•11 years ago
|
||
Yes, the spec is a little unclear on this issue. Please feel free to raise a spec issue :-)
Updated•11 years ago
|
status-b2g-v1.3T:
--- → fixed
Updated•10 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•