Closed Bug 272381 Opened 20 years ago Closed 20 years ago

Crash when printing a iframe [PoC included][@ GlobalWindowImpl::Print] GlobalWindowImpl::GetInterface is broken

Categories

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

x86
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: n.v.d.maas, Assigned: timeless)

References

()

Details

(Keywords: crash, Whiteboard: [sg:nse])

Crash Data

Attachments

(1 file, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Just discovered this crashing vulnerability when working on one of my projects, please take a look at the attached URL for the PoC. Mozilla (tried only Firefox) will crash when opening this page, tested on Firefox 1.0 final on the platforms Windows, Linux and SunOS. CC-ing this bug to the Mozilla Security Group, AFAIK it meets all the criteria. Reproducible: Always Steps to Reproduce: Go the the given URL (http://niekvandermaas.nl/zooi/firefox-crash.html) Actual Results: Firefox will crash Expected Results: Firefox will print the iframe
Additional information: Replacing the javascript with the following code makes the problem disappears: <a href="#" onclick="window.frames.pdfframe.print();">Click here to print</a> Also moving the javascript to onload (in the body tag) 'solves' the problem. So this crash only appears when directly executing the javascript in the document.
(In reply to comment #1) > -snip- > <a href="#" onclick="window.frames.pdfframe.print();">Click here to print</a> > -snip Of course that should be pocframe...
Blocks: sbb?
Can't reach your site, please add your testcase as an attachment to the bug.
Keywords: crash
Whiteboard: [sg:needinfo]
(In reply to comment #3) > Can't reach your site, please add your testcase as an attachment to the bug. My ISP has some problems, here's the testcase as an attachment.
Has anyone of the security team actually /looked/ at this bug? Alex's story comes to mind (http://weblogs.mozillazine.org/weirdal/archives/human259708.html)... If there are no objections, I will post this vulnerability tommorow on full-disclosure.
go away, this is a null pointer deref, however thanks to the security flag our normal qa was not able to see the bug and could not get a stack trace for us. it doesn't help that you filed this bug in the wrong product.
Assignee: firefox → general
Group: security
Component: General → DOM: Level 0
Product: Firefox → Core
QA Contact: firefox.general → ian
Whiteboard: [sg:needinfo] → [sg:nse] DUPEME
Version: unspecified → Trunk
Incident ID: 2389668 Stack Signature GlobalWindowImpl::Print() 368029c0 Product ID CaminoTrunk Build ID 2004120108 Trigger Time 2004-12-06 07:57:40.0 Platform MacOSX Operating System Darwin 7.6.0 Module Camino + (003a5284) URL visited https://bugzilla.mozilla.org/attachment.cgi?id=167454&action=view User Comments bug 272381 Since Last Crash 385065 sec Total Uptime 385065 sec Trigger Reason SIGBUS: Bus Error: (signal 10) Source File, Line No. /builds/camino-release/camino/trunk/mozilla/dom/src/base/nsGlobalWindow.cpp, line 848 Stack Trace GlobalWindowImpl::Print() [/builds/camino-release/camino/trunk/mozilla/dom/src/base/nsGlobalWindow.cpp, line 848] analysis: GetInterface returns NS_OK and outs null. this is absolutely broken. it can happen for all sorts of reasons because the code is really broken. it just needs to be fixed.
Summary: Crash when printing a iframe [PoC included] → Crash when printing a iframe [PoC included][@ GlobalWindowImpl::Print] GlobalWindowImpl::GetInterface is broken
Whiteboard: [sg:nse] DUPEME → [sg:nse]
Assignee: general → timeless
Status: UNCONFIRMED → ASSIGNED
Attachment #168028 - Flags: superreview?(jst)
Attachment #168028 - Flags: review?(jst)
Blocks: sbb-
No longer blocks: sbb?
Attachment #168028 - Flags: superreview?(jst)
Attachment #168028 - Flags: superreview+
Attachment #168028 - Flags: review?(jst)
Attachment #168028 - Flags: review+
Comment on attachment 168028 [details] [diff] [review] make GetInterface honor the interface mozilla/dom/src/base/nsGlobalWindow.cpp 1.715
Attachment #168028 - Attachment is obsolete: true
Comment on attachment 168028 [details] [diff] [review] make GetInterface honor the interface mozilla/dom/src/base/nsGlobalWindow.cpp 1.716 oh well, the test was reversed, but it was the right problem and fix.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment on attachment 168028 [details] [diff] [review] make GetInterface honor the interface > if (aIID.Equals(NS_GET_IID(nsIDocCharset))) { > if (mDocShell) { > nsCOMPtr<nsIDocCharset> docCharset(do_QueryInterface(mDocShell)); > if (docCharset) { > *aSink = docCharset; > NS_ADDREF(((nsISupports *) *aSink)); > } > } > } A common technique here would be: if (aIID.Equals(NS_GET_IID(nsIDocCharset))) { if (mDocShell) { return mDocShell->QueryInterface(aIID, aSink); } }
Can this be checked into the 1.0.x branch for 1.0.4? This seems to be only fixed on trunk. This crasher problem has given Firefox some really bad publicity in Poland, recently - http://di.com.pl/n/?lp=9796&r=1 (this is one of the major IT related vortals).
Flags: blocking-aviary1.0.4?
I'd say no. We should not panic just because some press decided to write a news about such "amazing" bug.
If attachment 168028 [details] [diff] [review] is what was checked in on trunk, it looks like a simple thing - changing just one line of the code. I don't think it would do any harm to the branch, while being good for marketing reasons. ;)
*** Bug 293919 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0.4?
Crash Signature: [@ GlobalWindowImpl::Print]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: