Closed Bug 273699 (sa13129) Opened 15 years ago Closed 15 years ago
2 Frame Injection Vulnerabilities (popup blocking race condition & onunload event mis-firing) [Secunia Advisory SA13129 moderately critical]
Secunia has reported there is frame injection vulnerability in Mozilla The test is a bit confusing, so here's the steps to reproduce (tested in Firefox 1.0) First test (w/ popup blocking) 1. enable popup blocker 2. open www.citibank.com/us/index.htm in one tab 3. open secunia.com/multiple_browsers_window_injection_vulnerability_test/ in another tab 4. in vulnerability test page, click "Test Now - With Pop-up Blocker - Left Click On This Link" 5. close the new CitiBank window that opens 6 returns to the CitiBlank tab, and click [(!)Consumer Alert] 2nd test (w/o pop-up blocking) 1. disable popup blocker 2. close the vulnerability test page if you had it opened 3. open secunia.com/multiple_browsers_window_injection_vulnerability_test/ 4. click "Test Now - Without Pop-up Blocker - Left Click On This Link" 5. in the CitiBlank window, click [(!)Consumer Alert] Results: CitiBank's popup gets replaced by Secunia content
Vulnerability 1 - Popup Racing When popup blocking is enabled, time-delayed popup (via setTimeout) can replace another popup opened by another site. This requires that 1. both sites attempt to open popups with the same name 2. the legit, 2nd popup is opened before the first one is detected (and hence blocked)
Vulnerability 2 - Event Misfiring Opening a named popup causes unonload event of another frame with the same name to fire, enabling it to replace the content of another popup.
Summary: Frame Injection Vulnerability (via unonload) → 2 Frame Injection Vulnerabilities (popup blocking race condition & onunload event mis-firing)
Summary: 2 Frame Injection Vulnerabilities (popup blocking race condition & onunload event mis-firing) → 2 Frame Injection Vulnerabilities (popup blocking race condition & onunload event mis-firing) [Secunia Advisory SA13129]
workaround fix for Firefox/Mozilla users added: http://mozillanews.org/?article_date=2004-12-08+06-48-46
This workaround enables Address Bar visible in opened window generated by for example Secunia's test page (and a fictional malicious Web site). When dom.disable_window_open_feature.location is set to 'true', the real address http://secunia.com/ resultpage / [broken with spaces] is showing.
Additional workaround is to install the Tabbrowser Extensions, and configure it to open popups in new tabs. This has been tested to block the sample code from Secunia.
Test case 1 above is invalid and the workaround published elsewhere does not appear to work. The test case does not work in the same way as http://secunia.com/multiple_browsers_window_injection_vulnerability_test/ To demonstrate, set the dom.disable_window_open_feature.location to 'true', then try test case 1 above. You'll get the genuine Citibank content in the popup window, and the popup does not show any location bar. Then go to http://secunia.com/multiple_browsers_window_injection_vulnerability_test/ and try Step 2 - With Popup Blocker. You'll get the spoofed content this time and the popup still does not show any location bar. This is using Firefox 1.0 on WinNT4 SP6a.
It looks like this is JS-specific, and it affects Firefox. Shouldn't the "product" be changed to whatever compenent deals with JS? Or to Firefox.
moving to Security General until further notice
Component: General → Security: General
OS: Windows XP → All
Product: Mozilla Application Suite → Core
Hardware: PC → All
Version: unspecified → Trunk
Another workaround is to set the old abandoned prefs browser.block.target_new_window to true, that opens the link in the current frame/window if the target is unknown/new.
*** Bug 273870 has been marked as a duplicate of this bug. ***
*** Bug 273848 has been marked as a duplicate of this bug. ***
Note that we have existing bugs on mistargeting, especially across windows and across security contexts. So this is a duplicate.
playing with testcase 2 abit, I found that it is only triggered when the original page is not in a background tab, if it was, the tab is closed and a new window is created. This isn't really new imho.
One other note. We have code in docshell that protects against this very exploit (to test that, replace window.open with <a target="">). The problem is that window.open() doesn't use the same target-finder as docshell does. So chances are, fixing bug 103638 will fix this too.
Depends on: 103638
Comment on attachment 168202 [details] testcase 1 - Time-Delayed Popup Replacing Frame of a Different Site (Race Condition) This test (and Secunia's test page) no longer demonstrate any problem because Citibank's site is no longer usable as an example of this bug. The next testcase should perhaps not rely on a bank to help demonstrate a spoofing vulnerability.
Attachment #168202 - Attachment is obsolete: true
(In reply to comment #15) > (From update of attachment 168202 [details] ) > This test (and Secunia's test page) no longer demonstrate any problem because > Citibank's site is no longer usable as an example of this bug. Secunia has updated their test page at http://secunia.com/multiple_browsers_window_injection_vulnerability_test/ they use now usatoday.com. only as note: Opera 7.54u1 has partly fixed the issue, see http://www.opera.com/support/search/supsearch.dml?index=782 and http://secunia.com/advisories/13253/. Konqueror/KDE 3.2.3 and 3.3.2 have fixed the issue, see http://www.kde.org/info/security/advisory-20041213-1.txt and http://secunia.com/advisories/13254/.
This only works if I deselect the "force links that open new windows to open in" checkbox in Firefox's Options->Advanced->Tabbed Browsing (pref "browser.link.open_newwindow" set to 2, which is the default).
(In reply to comment #17) > This only works if I deselect the "force links that open new windows to open in" > checkbox in Firefox's Options->Advanced->Tabbed Browsing (pref > "browser.link.open_newwindow" set to 2, which is the default). I do not see this preference in FF 1.0 on Linux. Furthermore, I have just verified that the testcase works with a fresh profile -- in other words, all defaults. Let's not discount this.
We're not discounting this spoof, work is progressing in bug 103638 (see "depends on" list above) that's intended to fix it.
is there a bug on the popup race condition in testcase 1?
*** Bug 274835 has been marked as a duplicate of this bug. ***
Yes, this should block 1.8a6
Flags: blocking1.8a6? → blocking1.8a6+
*** Bug 277114 has been marked as a duplicate of this bug. ***
Bug 103638 has landed so I'm resolving this as fixed per JST's comment #24.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Flags: blocking-aviary1.0.1? → blocking-aviary1.0.1+
Drivers would like this on the branches (plus fixes for regressions caused by 103638)
Whiteboard: [sg:fix] → [sg:fix] see bug 103638
Fixed for 1.7.6 too.
Verified Fixed with latest Aviary 1.0.1 and Mozilla 1.7.6 builds. Also looks good on the Trunk. No bad things happening with the USA Today Secunia testcase and with "dom.disable_window_open_feature.location" set to true, I see the expected url. However, with popup blocker enabled, Firefox notifies me that there are a bunch of windows being blocked from secunia (http://secunia.com/resultpage/). But I guess that means this fix is working. With popup blocker disabled, everything works fine.
Status: RESOLVED → VERIFIED
Summary: 2 Frame Injection Vulnerabilities (popup blocking race condition & onunload event mis-firing) [Secunia Advisory SA13129] → 2 Frame Injection Vulnerabilities (popup blocking race condition & onunload event mis-firing) [Secunia Advisory SA13129 moderately critical]
This is NOT FIXED as of 23-JUNE-2005, Mozilla 1.7.8. Using the page at secunia.com to check this vulnerability the Secunia site was able to inject their frame into an msdn framed page. Test page: http://secunia.com/multiple_browsers_frame_injection_vulnerability_test/ Now using Secunia is demonstrating the frame injection using Microsoft msdn, not USAtoday or citibank.
Re #30: Works in Deerpark as well, only with new window though. With "Force links that open new windows to open in" selected, and a "a new tab", it the injection opens a new tab.
That sounds like bug 296850 (regression, fixed on current branches).
Test for this got added in bug 408052.
You need to log in before you can comment on or make changes to this bug.