822215 - iframe-to-iframe cross-domain extraction method (UI Redressing)

Status: NEW

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Luca De Fulgentis]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

Hi Folks,
I found a new cross-domain content extraction method that could be used in order to exploit UI Redressing issue under Firefox. 
The extraction method is extremely simple: instead of performing a drag&drop action of sensitive data, from a framed vulnerable web page to the framing one (attacker-controlled), the victim is triggered to navigate a malicious html page that includes two iframes: the former frames the vulnerable page - where the sensitive content resides - while the latter frames another attacker's page that is used to drop the extracted content. Firefox is not able to block this kind of attack because no check on cross-domain drag&drop between iframes is performed. The (iframe-to-iframe) method was tested against the latest version of Firefox.
Further details can be found here: blog.nibblesec.org
Thanks,
Luca

Comment 1

[Daniel Veditz [:dveditz]]

As noted at http://blog.nibblesec.org/2012/12/ui-redressing-mayhem-firefox-0day-and.html dragging from a frame to a cross-origin parent was blocked by the fix in bug 605991.

It could be we don't want to address the drag and drop aspect of this--I bet it breaks a lot of things--but instead kill support for view-source: in anything but a top-level window/tab. I'm sure that will break things too (it'll break one of my old bookmarklets, for example) but since they will be Gecko-only things it's more defensible.

Comment 2

[Daniel Veditz [:dveditz]]

In addition to the nibblesec blog this was referenced at the end of a recent ThreatPost article, http://threatpost.com/en_us/blogs/chrome-clickjacking-vulnerability-could-expose-user-information-google-amazon-010213

Comment 3

[Jesse Ruderman]

Disabling "view-source:" for iframes won't really solve this, because plenty of sensitive data is shown as text.

Sounds to me like we just need to complete the fix for bug 605991, so it also applies to iframe-to-iframe dragging.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Neil want to take this one?

Comment 5

[Neil Deakin]

So the idea is to block dragging from a content frame to another content frame within the same toplevel parent?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

sounds like so. It is strict, but how else could this be resolved.

Comment 7

[Jan Jaeschke [:jjaschke]]

This came up in the DOM Core bug bash triage. Dan, is this still relevant?

Comment 8

[Daniel Veditz [:dveditz]]

Yes, Firefox is still unsafe compared to other browsers.

The specific attack outlined in the nibblesec blog won't work anymore because we restricted the ability to open view-source: URLs in bug 1172165, but as Jesse noted in comment 3, anything sensitive/private that's rendered in the document is still fair game for this attack.

Comment 9

[Daniel Veditz [:dveditz]]

Attachment: simplistic testcase

This testcase uses the default <textarea> drop behavior, nothing fancy. In Firefox you can't drag any text or the link out of the example.com frame and drop it on the parent document textarea, but you can still drag it to the textarea in a frame from a different origin. Here that frame happens to be same-origin with the parent for convenience, but we shouldn't allow drags to any other cross-origin frame either (an attacker can easily have two domains).

Compare the behavior in Chrome or Safari: these drops are not allowed.