Closed Bug 273699 (sa13129) Opened 20 years ago Closed 20 years ago

2 Frame Injection Vulnerabilities (popup blocking race condition & onunload event mis-firing) [Secunia Advisory SA13129 moderately critical]

Categories

(Core :: Security, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: danielwang, Assigned: dveditz)

References

()

Details

(Keywords: fixed-aviary1.0.1, fixed1.7.6, Whiteboard: [sg:fix] see bug 103638)

Attachments

(2 obsolete files)

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. ***
Alias: sa13129
*** 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.
Whiteboard: DUPEME
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
Flags: blocking1.7.5+
Assignee: security → dveditz
QA Contact: general
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
Attachment #168203 - Attachment is obsolete: true
(In reply to comment #15)
> (From update of attachment 168202 [details] [edit])
> 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?
Whiteboard: DUPEME → [sg:fix]
*** Bug 274835 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a6?
Yes, this should block 1.8a6
Flags: blocking1.8a6? → blocking1.8a6+
*** Bug 277114 has been marked as a duplicate of this bug. ***
For the record (and as mentioned in comment 19), the fix for this bug is in bug
103638.
Bug 103638 has landed so I'm resolving this as fixed per JST's comment #24.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1? → blocking-aviary1.0.1+
Drivers would like this on the branches (plus fixes for regressions caused by
103638)
Flags: blocking1.7.6+
Whiteboard: [sg:fix] → [sg:fix] see bug 103638
jst checked bug 103638 and regression fixes into the aviary branch
Fixed for 1.7.6 too.
Keywords: fixed1.7.6
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.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.