343168 - frame spoofing using document.open()

Status: VERIFIED FIXED

(Core :: Security, defect, P2)

Description

[shutdown]

You can replace framed contents using target.frames[n].document.open().
Something similar to bug 13871, bug 20682, bug 246448, and bug 296850.

Comment 1

[shutdown]

Attachment: testcase

works on:

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a3)
  Gecko/20060629 BonEcho/2.0a3
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.5)
  Gecko/20060629 Firefox/1.5.0.5

Comment 2

[Boris Zbarsky [:bzbarsky]]

So I think we should leave document.open/document.close as allAccess, but in those methods do a security check that checks whether the caller can access the our window's frameElement, if there's a non-null frameElement.  If not, throw a security exception.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Something like this

Comment 4

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 227624 [details] [diff] [review]
Something like this

We need to use GetFrameElement(), not GetFrameElementInternal(); otherwise you can't document.open a document in a toplevel window you just opened via window.open...

And we need a similar check in ::Close().

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #4)
> (From update of attachment 227624 [details] [diff] [review] [edit])
> We need to use GetFrameElement(), not GetFrameElementInternal(); otherwise you
> can't document.open a document in a toplevel window you just opened via
> window.open...

Oops, I didn't quite understand the difference between GetFrameElement and GetFrameElementInternal. Fixed.

> And we need a similar check in ::Close().

So, why is HTMLDocument.close.get allAccess anyway? What possible use-case is there for closing a generated document that you don't own? It seems that this capability was added for bug 54060 (and previously, somewhere for the XPCDOM landing). Was this simple over-zealousness (it seems that there were problems dealing with javascript: generated pages having bad principals back then, but those should now go away)?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm.  Good point.  I'd be happy to make close() same-origin (with some testing, etc).

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Better patch

I haven't yet tested this, but will tomorrow.

Comment 8

[Daniel Veditz [:dveditz]]

Blake, did you ever test your "Better patch"?

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 227766 [details] [diff] [review]
Better patch

Yeah, this works.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 227766 [details] [diff] [review]
Better patch

Looks good!

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into trunk.

Comment 12

[Mike Schroepfer]

Comment on attachment 227766 [details] [diff] [review]
Better patch

a=schrep for drivers.  Land away!

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Checked in on the 1.8 branch.

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 227766 [details] [diff] [review]
Better patch

approved for 1.8.0. branch, a=dveditz for drivers

Comment 15

[Blake Kaplan (:mrbkap) (inactive)]

Fixed on the 1.8.0 branch.

Comment 16

[alice nodelman [:alice] [:anode]]

https://bugzilla.mozilla.org/attachment.cgi?id=227580&action=view shouldn't cause an exploit (no "ALL YOUR FRAMES ARE BELONG TO US")

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1b2) Gecko/20060825 BonEcho/2.0b2

verified 1.8.1b2

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7pre) Gecko/20060825 Firefox/1.5.0.7pre

verified 1.8.0.7

Comment 17

[Boris Zbarsky [:bzbarsky]]

This caused bug 362837.

Comment 18

[Boris Zbarsky [:bzbarsky]]

So the fixes checked in on 1.8.0 and 1.8/trunk are different.  The 1.8.0 fix does the security check only if !mParser, while the 1.8/trunk fix does it no matter whether mParser is set; hence the difference in behavior in bug 362837.

It seems to me that the checks should be consistent, and I think I would probably go with the 1.8/trunk version so you can't inject content into a document while it's loading, right?

Comment 19

[Boris Zbarsky [:bzbarsky]]

Need support for multiple domains in mochitest to add a test...

Comment 20

[Daniel Veditz [:dveditz]]

Blake should make the call, but it looks to me like the 1.8.0 code is the correct one: if we've already opened the document (mParser exists) we don't need to reopen it and no need to check permissions at that point. If the security checks are necessary then they ought to be moved into document.write itself rather than relying on checks in the implied .open() which will only happen if !mParser.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Ah, right.  Since Write() doesn't doesn't call Open() if !mParser, we should indeed not be doing the check in Open() when !mParser.

Comment 26

[Ronen Zilberman]

I've opened a new bug for this: Bug 381300

Comment 27

[Daniel Veditz [:dveditz]]

Comments 22-25 relate to new bug 381300