Closed Bug 272381 Opened 15 years ago Closed 15 years ago

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

Categories

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

x86
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

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

References

(Blocks 1 open bug, )

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: 15 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.