277554 - Content can be manipulated by another site with a popup window

Status: RESOLVED WONTFIX

(Core :: Security, defect)

Description

[u115577]

With a popup window, you can manipulate the content of linked page.

Testcase 1: http://beta51.minutedesign.com/test1.html
Linked page is mozilla.org, but immediately replaced to MozillaZine.

Testcase 2: http://beta51.minutedesign.com/test2.html
Linked page is Yahoo!, but immediately rewritten with a fake content.
The certificate is also spoofable.

Comment 1

[u115577]

I reported Bug 277564 about certificate spoofing.

Comment 2

[u115577]

Better testcase
http://beta51.minutedesign.com/test1-2.html
http://beta51.minutedesign.com/test2-2.html

Comment 3

[u115577]

In function rewrite(), 
"window.opener.document.URL"
 - Error: uncaught exception: Permission denied to get property HTMLDocument.URL
"window.opener.document.open()"
 - No error. This should be denied.

Comment 4

[timeless]

testcase 2 from comment 0 and comment 1 lead me to:
wyciwyg://10/http://beta51.minutedesign.com/test2.html

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041225
Camino/0.8+

please always include a build id if you have one ...

Comment 5

[u115577]

I tested on Firefox nightly build (trunk):
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20050105
Firefox/1.0+

Comment 6

[u115577]

Attachment: testcase

Simple test case to avoid confusion with Bug 277564 (certificate spoofing)

Comment 7

[u115577]

Attachment 170773 [details] doesn't work...??
Test http://beta51.minutedesign.com/test3.html instead.

Comment 8

[Daniel Veditz [:dveditz]]

Leaving aside test2 (better covered in bug 277564), I don't see what the problem
is with your original tests? What I see with test1 and 2 (original) is
 1) WindowA/SiteA opens PopupB
 2) ...user surfs in WindowA to SiteC...
 3) PopupB changes content of WindowA
 4) Location bar in WindowA reflects the fact that popupB changed it

This is something any window can legitimately do to any window it has a
reference to. It's unable to access any properties of the other window if it's
from a different origin, but it can change it to a different location or write
out a new page. In either case the location bar will reflect the new location or
the origin of the page doing the writing.

[Bug: the original title is not cleared by document.open() although the location
bar is updated immediately. Sometimes the title is cleared on the first
document.write(), or close() if no writes, though in test3.html the Mozillazine
title sticks around. But that's not a big danger, the spoof content could just
duplicate the title anyways]

The updated testcases are more interesting to me. The onunload property is
normally unreachable from the popup; I guess here it's set before the origin
changes so it's allowed, but it's hard to believe we're opening up a whole new
popup and running its code before the opener's origin has changed. But the
timeout *fires* long after the new page has loaded and appears to have access to
the new page's DOM.

document.location gives me the attack site (beta51.minutedesign.com), but
document.links[0] for example has access to the Mozillazine content (assuming I
don't call document.open() which does reset things). Hm, document.cookie comes
up blank, though, so that looks like the minutedesign.com cookies.

A bad state, anyway.

Comment 9

[Daniel Veditz [:dveditz]]

The part I'm concerned about might be covered by Johnny's updated patch to
address bug 277564.

Comment 10

[u115577]

My testcase sometimes doesn't work due to a short time to call setTimeout.
Save test3 http://beta51.minutedesign.com/test3.html to hard disk and extend
setTimeout from 3000 to 10000 or so.

 1) WindowA/SiteA opens PopupB
 2) ...user surfs in WindowA to SiteC...
 3) SiteC is loaded in WindowA

 (wait for a moment)

 4a) PopupB rewrites content of SiteC
 4b) PopupB redirects SiteC to SiteD
 5) Location bar in WindowA reflects the fact that popupB changed it

Patch
https://bugzilla.mozilla.org/show_bug.cgi?id=277564#c14

To avoid redirection, this is also needed.
-pref("capability.policy.default.Location.replace.get", "allAccess");

Comment 11

[u115577]

Redirection in this case may be allowed... It's my misconception.
Problem is content rewriting via document.write().

Comment 12

[Daniel Veditz [:dveditz]]

I guess I'm not getting the point of what remains of this bug. test3 is not
rewriting the content of SiteC, it is opening a new document and writing to it.
Setting window.opener.location.href is allowed, why shouldn't writing out a new
document be considered the same thing?

Given that any spoofing possibility here relies on users not noticing the urlbar
(since that's now updated correctly -- thank you for pointing out bug 277564!)
then the attacker would have an easier job simply opening a target-spoof right
off the initial click, without the possibly attention-grabbing weirdness of the
tiny popup and page "refresh" (if you managed to document.write() an exact
duplicate).

Comment 13

[Daniel Veditz [:dveditz]]

Clearing security flag now that case 2 (spun off as bug 277564) has been fixed.

Comment 14

[Tom Ritter [:tjr]]

To fix this would require backwards-incompatible changed to the Web, regrettably. noopener and COOP are what we settled on to allow websites to protect themselves against this type of attack.