382686 - [mz2] iframes from other sites can be changed while pointing at about:blank

Status: RESOLVED DUPLICATE of bug 381300

(Core :: DOM: Core & HTML, defect)

Description

[Michal Zalewski]

Firefox seems to allow third parties to replace IFRAME data of unrelated webpages by enabling non-same-domain sites to perform:

  foo = open("","target_name");
  foo.frames['bar'].document.open();
  foo.frames['bar'].document.write(...);
  foo.frames['bar'].document.close();

Where "target_name" is established by being opener of the targeted window, or setting window name before the user navigated away from the attack site, or knowing name assigned by the attacked site (if any).

Now, although newly written IFRAME data will inherit its location and permission from the writing page (and thus won't be able to directly interact with page elements or read window.top.document.cookie), it will be able to pull a couple of nasty tricks, say:

1) Call window.focus() and use onkeydown handler to intercept user's keystrokes on that site.

2) Display offensive, misleading or dangerous contents on trusted sites (spoofed login prompts, etc).

3) Track user behavior, including precise timing of arrival and departure, based on presence of named IFRAMEs.

Visible IFRAMEs are often used to render nested contents (forum or blog posts, photos, advertisements, etc) on various pages; and hidden IFRAMEs are commonly employed for user tracking or pre-XMLHttpRequest browser-server communications. As such, a good number of sites is affected one way or another. 

In general, it sounds like a good idea to restrict document.write and other types of interaction with all types of frames based on creator's domain.

Comment 1

[Michal Zalewski]

test case added

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #2)
> *** This bug has been marked as a duplicate of bug 343168 ***

That bug is marked fixed1.8.1 - why does this testcase still "work" on branch 1.8 builds?

Comment 4

[Michal Zalewski]

Jonas - good catch, but as Gavin pointed out, bug 343168 does not resolve this testcase. My initial description was vague, but this is a related, yet distinctive problem.

The problem you fixed there is that document.write() could be used to overwrite frames that originate from Internet-based SRC= pointing to non-same-domain site. This is fixed and throws a security exception.

Unfortunately, the check implemented means that about:blank frames can be overwritten freely; and unfortunately, *all* frames, even with Internet SRC= specified, will be vulnerable to a race condition while the document loads (see a modified version of bug 343168 testcase here):

http://lcamtuf.coredump.cx/ifsnatch/modified.html 

You might want to rename this bug to include 'about:blank' in its title and reopen it. The only sane fix I see is to enforce frame policy based on frame parent's origin, too (will significantly limit exposure).

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Blake, can we special-case about:blank if the containing frame element is from another domain?

Comment 6

[Jesse Ruderman]

The race condition is bug 381300, "Frame spoofing is possible within a short time frame while the window is loading".  That bug also mentions the about:blank issue; I think the two issues are connected.

Comment 7

[Michal Zalewski]

Yup, bug 381300 is far closer (you might want to check both testcases on trunk to confirm whether the about:blank fix implemented there would be sufficient).

Certainly the risk of 381300 is understated; spoofing is not the only attack possible (see cnn.com example).

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Jonas, yeah, we could probably do that. We might need to deal with compat issues, though.

This bug only exists on the 1.8 branch, right? I believe that Boris implemented basically what Michal describes in the last paragraph of comment 4 in bug 332182.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Unfortunately, the check implemented means that about:blank frames can be
> overwritten freely

Right.  Because we have to check that caller can access |this| as well, and anyone can access about:blank on branch.  Perhaps for about:blank documents on branch, we should skip the "caller can access |this|" part, or replace it with "caller is this document itself".  That _should_ be ok regression-wise.

And yes, there should be no problem with about:blank on trunk.  

Comment 10

[Ronen Zilberman]

This is a duplicate of Bug 381300

Comment 12

[Bob Clary [:bc] (inactive)]

publicly disclosed by Michal Zalewski to full-disclosure.

Comment 13

[Daniel Veditz [:dveditz]]

According to http://archives.neohapsis.com/archives/fulldisclosure/2007-06/0026.html
bug 381300 is "a less severe variant" -- in what way is it a different bug?

Comment 14

[Michal Zalewski]

The underlying bug is very much the same. The reported attack scenario differs from this entry in two aspects: the initial report considered only a more benign opportunity (page element spoofing vs snooping on user input), and did not account for the possibility that persistent about:blank frames that do not require a race condition to occur (which is important when considering a proper fix; but that point is moot if you plan to backport a more comprehensive fix from trunk).

Otherwise, same old. That's all I wanted to say there.

Comment 15

[Daniel Veditz [:dveditz]]

Marking blocking so we remember to verify that a fix for bug 381300 really does fix this testcase as well.

Comment 16

[Daniel Veditz [:dveditz]]

fix for bug 381300 landed on the 1.8 branch

Comment 17

[Daniel Veditz [:dveditz]]

Not needed for Thunderbird 1.5.0.13, up to vendors if they want it for future Firefox 1.5 versions.