1.93 KB, text/html
58.24 KB, patch
|Details | Diff | Splinter Review|
57.36 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20070309 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20070309 Firefox/126.96.36.199 When opening a window from a script, it is possible to spoof the content of the newly opened window's frames within a short time frame, while the window is loading. Because the exact time is non-constant and unknown, multiple attempt are carried out. The failed ones are silently discarded using a try catch block. This is similar to Bug 343168. Both the 'frames[x].document.open()' method (described in above bug) and a normal 'frames[x].document' method are shown to reliably produce the exploit. Reproducible: Always Steps to Reproduce: See attached test case.
I can reproduce this with a current branch build, but not on the trunk.
Component: Security → DOM
Whiteboard: [sg:low spoof]
Assignee: dveditz → jst
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:low spoof] → [sg:low spoof] 1.8-branch only?
Version: unspecified → 1.8 Branch
It seems that the problem is this: The frame's location is "about:blank" while it is being loaded, and it is during this time that it can be spoofed (after the parent document has been loaded, but before the framed document has been loaded).
This was fixed on the trunk by changing the way we treat about:blank
Whiteboard: [sg:low spoof] 1.8-branch only? → [sg:low spoof] 1.8-branch only
I wonder whether we could at least port part of that (e.g. the default principal for subframes)... Not sure how easy that would be.
publicly disclosed by Michal Zalewski to full-disclosure.
CC list accessible: false
Not accessible to reporter
The trunk fix was in bug 332182. Looking at it now, it might not be impossible to merge to branch, if we're sure it doesn't break the web (which seems likely). Some of the code is sure to not apply, and we'd need to add interfaces instead of changing them, but it might be doable in general.... Unfortunately, I'm not going to be able to do it in the near future. :(
I think it's a critical vulnerability, do I? It's very dangerous if someone using this exploit to steal accounts.. I really appreciate if you can fix this since next branch build..
This bug got some publicity and one bank tells their users to 'stop using Firefox until it's fixed and switch to IE6'. http://www.multibank.pl/co_nowego/aktualnosci?_a=15793
It is gaining in publicity. NIST's Vulnerability DB lists the CVSS Severity at a 10.0(High) http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-3089 All Fx users at my work got a message from our corp security team last week telling us to uninstall Fx immediately.
I've confirmed that this patch fixes the "exploit testcase" in this bug. I have NOT had a chance to do any other testing yet. In particular, I have not run it on the tests attached to bug 332182. It would be great if someone would, with all the various new-window pref settings (at the very least, with the settings to force all new windows into windows, tabs, and same rendering area). Note that the tests can be run with jssh; I think we have some documentation on mozilla.org for that. I'll try to get this also ported to the 1.8.0 branch.
I should also note that if run under jssh the tests will do the different pref values automatically... So that's really the way to go, imo.
Works with all the testcases from bug 332182 here, on Firefox 188.8.131.52+patch.
I'm basically gone starting today for two weeks or so. jst or Blake, could you drive this in? I don't have the 1.8.0 port done (or even significantly started), unfortunately. :(
Whiteboard: [sg:low spoof] 1.8-branch only → [sg:low spoof] 1.8-branch only, need r=mrbkap, sr=jst
required to fix public exploit bug 382686
Comment on attachment 269025 [details] [diff] [review] Backport of fix for bug 325816 and bug 332182 to 1.8 branch Looks good to me, sr=jst. I happened to spot one typo in surrounding code as I was reading through it, fix it if you want to: - In nsDocShell::DoURILoad(): // XXX: Is seems wrong that the owner is ignored - even if one is
Attachment #269025 - Flags: superreview?(jst) → superreview+
Comment on attachment 269025 [details] [diff] [review] Backport of fix for bug 325816 and bug 332182 to 1.8 branch *stamp*
Attachment #269025 - Flags: review?(mrbkap) → review+
Comment on attachment 269025 [details] [diff] [review] Backport of fix for bug 325816 and bug 332182 to 1.8 branch Hoping for some last-minute approval love.
Attachment #269025 - Flags: approval184.108.40.206?
Comment on attachment 269025 [details] [diff] [review] Backport of fix for bug 325816 and bug 332182 to 1.8 branch approved for 220.127.116.11, a=dveditz
Attachment #269025 - Flags: approval18.104.22.168? → approval22.214.171.124+
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Please see bug 387979.
Verified using test cases in comment #1 on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/2007071317 Firefox/188.8.131.52. Also on Mac 2005rc2 build.
In the interest of getting a Thunderbird 184.108.40.206 out ASAP to address the known problems, this spoofing bug will need to wait for 220.127.116.11 releases
Flags: blocking18.104.22.168+ → blocking22.214.171.124+
Attachment #271902 - Flags: approval126.96.36.199? → approval188.8.131.52?
Not needed in a Thunderbird 1.8.0 release, still wanted for browsers
Comment on attachment 271902 [details] [diff] [review] 1.8.0 branch patch a=caillon for 184.108.40.206 (and clearing stale .14 request)
Whiteboard: [sg:low spoof] 1.8-branch only, need r=mrbkap, sr=jst → [check in on 1.8.0. Bug 388121 MUST land with it][sg:low spoof] 1.8-branch only, need r=mrbkap, sr=jst
MOZILLA_1_8_0_BRANCH: Checking in caps/src/nsPrincipal.cpp; /cvsroot/mozilla/caps/src/nsPrincipal.cpp,v <-- nsPrincipal.cpp new revision: 220.127.116.11.2.1; previous revision: 18.104.22.168 done Checking in caps/src/nsScriptSecurityManager.cpp; /cvsroot/mozilla/caps/src/nsScriptSecurityManager.cpp,v <-- nsScriptSecurityManager.cpp new revision: 1.222.214.171.124.11; previous revision: 1.2126.96.36.199.10 done Checking in content/base/src/nsFrameLoader.cpp; /cvsroot/mozilla/content/base/src/nsFrameLoader.cpp,v <-- nsFrameLoader.cpp new revision: 188.8.131.52.4.2; previous revision: 184.108.40.206.4.1 done Checking in content/base/src/nsDocument.h; /cvsroot/mozilla/content/base/src/nsDocument.h,v <-- nsDocument.h new revision: 3.2220.127.116.11.5; previous revision: 3.218.104.22.168.4 done Checking in content/base/src/nsDocument.cpp; /cvsroot/mozilla/content/base/src/nsDocument.cpp,v <-- nsDocument.cpp new revision: 3.522.214.171.124.17; previous revision: 3.5126.96.36.199.16 done Checking in docshell/base/nsDocShell.cpp; /cvsroot/mozilla/docshell/base/nsDocShell.cpp,v <-- nsDocShell.cpp new revision: 1.7188.8.131.52.14; previous revision: 1.7184.108.40.206.13 done Checking in docshell/base/nsDocShell.h; /cvsroot/mozilla/docshell/base/nsDocShell.h,v <-- nsDocShell.h new revision: 220.127.116.11.2.2; previous revision: 18.104.22.168.2.1 done Checking in dom/public/base/nsPIDOMWindow.h; /cvsroot/mozilla/dom/public/base/nsPIDOMWindow.h,v <-- nsPIDOMWindow.h new revision: 22.214.171.124.4.1; previous revision: 126.96.36.199 done Checking in dom/src/base/nsGlobalWindow.cpp; /cvsroot/mozilla/dom/src/base/nsGlobalWindow.cpp,v <-- nsGlobalWindow.cpp new revision: 1.7188.8.131.52.23; previous revision: 1.7184.108.40.206.22 done Checking in dom/src/base/nsGlobalWindow.h; /cvsroot/mozilla/dom/src/base/nsGlobalWindow.h,v <-- nsGlobalWindow.h new revision: 220.127.116.11.2.4; previous revision: 18.104.22.168.2.3 done Checking in embedding/components/windowwatcher/src/Makefile.in; /cvsroot/mozilla/embedding/components/windowwatcher/src/Makefile.in,v <-- Makefile.in new revision: 22.214.171.124; previous revision: 1.26 done Checking in embedding/components/windowwatcher/src/nsWindowWatcher.h; /cvsroot/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.h,v <-- nsWindowWatcher.h new revision: 126.96.36.199.4.2; previous revision: 188.8.131.52.4.1 done Checking in embedding/components/windowwatcher/src/nsWindowWatcher.cpp; /cvsroot/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp,v <-- nsWindowWatcher.cpp new revision: 184.108.40.206.2.4; previous revision: 220.127.116.11.2.3 done Checking in dom/src/jsurl/nsJSProtocolHandler.cpp; /cvsroot/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp,v <-- nsJSProtocolHandler.cpp new revision: 18.104.22.168.2.5; previous revision: 22.214.171.124.2.4 done Checking in content/html/document/src/nsHTMLDocument.cpp; /cvsroot/mozilla/content/html/document/src/nsHTMLDocument.cpp,v <-- nsHTMLDocument.cpp new revision: 3.6126.96.36.199.17; previous revision: 3.6188.8.131.52.16 done Checking in content/base/public/nsIDocument.h; /cvsroot/mozilla/content/base/public/nsIDocument.h,v <-- nsIDocument.h new revision: 184.108.40.206.4.4; previous revision: 220.127.116.11.4.3 done
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.