fixed1.7.13, fixed1.8, qawanted
Closed window holds its last security context, but does not perform any security checks.
Created attachment 200430 [details] 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
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.
Assignee: general → jst
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:moderate] stepping stone
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.
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.
My branch build does the same thing.
I tested Firefox 1.0.6 (win32) and I see the same thing as well (exception thrown).
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).
In case it matters, I was testing with "Force links that open new windows to open in new tabs instead" checked.
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.)
Hmm... so what security checks do we do differently here when the thing lives in a tab?
Created attachment 200696 [details] xss testcase XSS testcase for reference. works on 20051021 or older builds. Of course, this does not work on latest trunk/mozilla1.8 builds.
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?
Flags: blocking1.8rc1? → blocking1.8rc1-
We can mark this fixed for trunk/1.8 due to bug 313236
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Depends on: 313236
Resolution: --- → FIXED
Whiteboard: [sg:high] XSS → [sg:high] XSS fixed by 313236
Keywords: fixed-aviary1.0.8, fixed1.7.13, fixed1.8
qawanted to make sure the bug 313236 really fixed this in older branches.
I tested these in ff 1.0.8 on all three platforms and passed each.
Keywords: fixed-aviary1.0.8 → verified-aviary1.0.8
You need to log in before you can comment on or make changes to this bug.