The default bug view has changed. See this FAQ.

frame spoofing using document.open()

VERIFIED FIXED in mozilla1.9alpha1

Status

()

Core
Security
P2
normal
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: shutdown, Assigned: mrbkap)

Tracking

({verified1.8.0.7, verified1.8.1})

Trunk
mozilla1.9alpha1
verified1.8.0.7, verified1.8.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9a1 +
blocking1.8.1 +
blocking1.8.0.7 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low spoof])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

11 years ago
Created attachment 227580 [details]
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
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.
(Assignee)

Updated

11 years ago
Priority: -- → P2
Target Milestone: --- → mozilla1.9alpha
(Assignee)

Comment 3

11 years ago
Created attachment 227624 [details] [diff] [review]
Something like this
Assignee: dveditz → mrbkap
Status: NEW → ASSIGNED
Attachment #227624 - Flags: superreview?(bzbarsky)
Attachment #227624 - Flags: review?(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().
Attachment #227624 - Flags: superreview?(bzbarsky)
Attachment #227624 - Flags: superreview-
Attachment #227624 - Flags: review?(bzbarsky)
Attachment #227624 - Flags: review-
(Assignee)

Comment 5

11 years ago
(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)?
Hmm.  Good point.  I'd be happy to make close() same-origin (with some testing, etc).
(Assignee)

Comment 7

11 years ago
Created attachment 227766 [details] [diff] [review]
Better patch

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

Updated

11 years ago
Attachment #227624 - Attachment is obsolete: true
Flags: blocking1.9a1+
Flags: blocking1.8.1?
Flags: blocking1.8.0.6?
Whiteboard: [sg:low spoof]

Updated

11 years ago
Flags: blocking1.8.1? → blocking1.8.1+
Blake, did you ever test your "Better patch"?
Flags: blocking1.8.0.6? → blocking1.8.0.6+
Whiteboard: [sg:low spoof] → [sg:low spoof][at risk]
(Assignee)

Comment 9

11 years ago
Comment on attachment 227766 [details] [diff] [review]
Better patch

Yeah, this works.
Attachment #227766 - Flags: superreview?(bzbarsky)
Attachment #227766 - Flags: review?(bzbarsky)
Comment on attachment 227766 [details] [diff] [review]
Better patch

Looks good!
Attachment #227766 - Flags: superreview?(bzbarsky)
Attachment #227766 - Flags: superreview+
Attachment #227766 - Flags: review?(bzbarsky)
Attachment #227766 - Flags: review+
(Assignee)

Comment 11

11 years ago
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Attachment #227766 - Flags: approval1.8.1?

Updated

11 years ago
Whiteboard: [sg:low spoof][at risk] → [sg:low spoof][at risk][baking until 8/3]

Comment 12

11 years ago
Comment on attachment 227766 [details] [diff] [review]
Better patch

a=schrep for drivers.  Land away!
Attachment #227766 - Flags: approval1.8.1? → approval1.8.1+
(Assignee)

Comment 13

11 years ago
Checked in on the 1.8 branch.
Keywords: fixed1.8.1
Whiteboard: [sg:low spoof][at risk][baking until 8/3] → [sg:low spoof][at risk]
Attachment #227766 - Flags: approval1.8.0.7?
Comment on attachment 227766 [details] [diff] [review]
Better patch

approved for 1.8.0. branch, a=dveditz for drivers
Attachment #227766 - Flags: approval1.8.0.7? → approval1.8.0.7+
(Assignee)

Comment 15

11 years ago
Fixed on the 1.8.0 branch.
Keywords: fixed1.8.0.7
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
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.0.7, fixed1.8.1 → verified1.8.0.7, verified1.8.1
Group: security
Whiteboard: [sg:low spoof][at risk] → [sg:low spoof]

Updated

11 years ago
Depends on: 362837
This caused bug 362837.
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?
Need support for multiple domains in mochitest to add a test...
Flags: in-testsuite?
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.
Ah, right.  Since Write() doesn't doesn't call Open() if !mParser, we should indeed not be doing the check in Open() when !mParser.
Depends on: 364309

Comment 26

10 years ago
I've opened a new bug for this: Bug 381300
Comments 22-25 relate to new bug 381300
Duplicate of this bug: 382686
You need to log in before you can comment on or make changes to this bug.