Last Comment Bug 382686 - [mz2] iframes from other sites can be changed while pointing at about:blank
: [mz2] iframes from other sites can be changed while pointing at about:blank
Status: RESOLVED DUPLICATE of bug 381300
[sg:low spoof]
: fixed1.8.1.5
Product: Core
Classification: Components
Component: DOM (show other bugs)
: unspecified
: All All
-- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on: CVE-2007-3089
  Show dependency treegraph
Reported: 2007-05-31 14:44 PDT by Michal Zalewski
Modified: 2007-08-06 12:24 PDT (History)
16 users (show)
bzbarsky: blocking1.9-
dveditz: blocking1.8.1.5+
dveditz: wanted1.8.1.x+
dveditz: wanted1.8.0.x+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Michal Zalewski 2007-05-31 14:44:20 PDT
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");

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, 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 User image Michal Zalewski 2007-05-31 15:25:19 PDT
test case added
Comment 2 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-05-31 18:10:41 PDT

*** This bug has been marked as a duplicate of bug 343168 ***
Comment 3 User image :Gavin Sharp [email:] 2007-05-31 18:48:54 PDT
(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 User image Michal Zalewski 2007-06-01 00:16:07 PDT
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): 

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 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-06-01 00:51:56 PDT
Blake, can we special-case about:blank if the containing frame element is from another domain?
Comment 6 User image Jesse Ruderman 2007-06-01 01:00:27 PDT
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 User image Michal Zalewski 2007-06-01 01:20:54 PDT
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 example).
Comment 8 User image Blake Kaplan (:mrbkap) 2007-06-01 01:25:58 PDT
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 User image Boris Zbarsky [:bz] (still a bit busy) 2007-06-01 06:09:21 PDT
> 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 User image Ronen Zilberman 2007-06-03 05:34:37 PDT
This is a duplicate of Bug 381300
Comment 11 User image Bob Clary [:bc:] 2007-06-04 10:35:25 PDT

*** This bug has been marked as a duplicate of bug 381300 ***
Comment 12 User image Bob Clary [:bc:] 2007-06-04 10:36:34 PDT
publicly disclosed by Michal Zalewski to full-disclosure.
Comment 13 User image Daniel Veditz [:dveditz] 2007-06-04 10:47:52 PDT
According to
bug 381300 is "a less severe variant" -- in what way is it a different bug?
Comment 14 User image Michal Zalewski 2007-06-04 10:59:23 PDT
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 User image Daniel Veditz [:dveditz] 2007-06-14 10:35:19 PDT
Marking blocking so we remember to verify that a fix for bug 381300 really does fix this testcase as well.
Comment 16 User image Daniel Veditz [:dveditz] 2007-07-11 11:34:05 PDT
fix for bug 381300 landed on the 1.8 branch
Comment 17 User image Daniel Veditz [:dveditz] 2007-08-06 12:24:39 PDT
Not needed for Thunderbird, up to vendors if they want it for future Firefox 1.5 versions.

Note You need to log in before you can comment on or make changes to this bug.