313366 - closed window holds its last security context

Status: RESOLVED FIXED

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

Description

[shutdown]

Closed window holds its last security context,
but does not perform any security checks.

Comment 1

[shutdown]

Attachment: testcase

Works on:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051021 Firefox/1.6a1
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b5) Gecko/20051021 Firefox/1.5
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.12) Gecko/20051021 Firefox/1.0.7

Comment 2

[Daniel Veditz [:dveditz]]

I swear I've recently seen a similar sounding bug that involved playing with closed windows, but I can't find it now.

Confirming. This could lead to an automatic arbitrary code exploit if combined with another bug that allows a CheckLoadURI bypass. Without such a second bug this could still be used as an arbitrary code execution if you can convince a user to open a privileged page in the new window (by typing it into the url bar). That seems somewhat remote, but you might be able to convince a few people (until the word got out) that you were offering useful pref-twiddling steps. Or maybe you could convince someone to drag a disguised chrome URL to the location bar.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So.. a trunk seamonkey gives me a security exception.  A trunk firefox doesn't even open a window on window.open(), so clearly something is badly busted there.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

My trunk firefox (pulled at 11:30 today) throws a security exception as well. I'm pulling a branch firefox even as I type this.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

My branch build does the same thing.

Comment 6

[Johnny Stenback (:jst)]

I tested Firefox 1.0.6 (win32) and I see the same thing as well (exception thrown).

Comment 7

[Jesse Ruderman]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051021 Firefox/1.6a1 - attack succeeds

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051022 Firefox/1.6a1 - attack fails with the following error message:

Error: function Function must be called directly, and not by way of a function of another name
Source File: https://bugzilla.mozilla.org/attachment.cgi?id=200430&action=view
Line: 17

That check was added by mrbkap in bug 313236 (the "shinier belt" patch).

Comment 8

[Jesse Ruderman]

In case it matters, I was testing with "Force links that open new windows to open in new tabs instead" checked.

Comment 9

[Jesse Ruderman]

I was able to reproduce in Firefox 1.0.7 RC2, but only after checking "Force links that open new windows to open in new tabs instead", which is hidden in 1.0.x.  (I made browser.tabs.showSingleWindowModePrefs true to make the pref appear.)

Comment 10

[Boris Zbarsky [:bzbarsky]]

Hmm... so what security checks do we do differently here when the thing lives in a tab?

Comment 11

[shutdown]

Attachment: xss testcase

SS testcase for reference. works on 20051021 or older builds.
Of course, this does not work on latest trunk/mozilla1.8 builds.

Comment 12

[Asa Dotzler [:asa]]

Dan, can you look into this further? What would it take to get a fix for this and what kind of risk would that add to our release?

Comment 13

[Daniel Veditz [:dveditz]]

We can mark this fixed for trunk/1.8 due to bug 313236

Comment 14

[Daniel Veditz [:dveditz]]

qawanted to make sure the bug 313236 really fixed this in older branches.

Comment 15

[Bob Clary [:bc] (inactive)]

I tested these in ff 1.0.8 on all three platforms and passed each.