Firefox 15.0.1 crash using window.showModalDialog()

NEW
Unassigned

Status

()

Core
DOM
--
critical
5 years ago
a year ago

People

(Reporter: Jordi Chancel, Unassigned)

Tracking

({crash, csectype-oom})

15 Branch
x86_64
Windows 7
crash, csectype-oom
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox47 affected, firefox48 affected, firefox-esr45 affected)

Details

(crash signature, URL)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 665838 [details]
showModalDialogcrash.htm

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

https://crash-stats.mozilla.com/report/index/b483b86a-80ce-4802-8029-e92852120928

Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x134

Visiting a webpage with a special javascript with some window.showModalDialog()

Like : 
<body onload="javascript:crash();"></body>
<script>
function crash() {
var string1 = unescape("%u0000%udead");
for (i =0;i<10000;i++) {
string1+=string1+string1;
window.showModalDialog(string1, string1, "dialogHeight:300px; dialogLeft:200px;");
}
}
</script>


Actual results:

firefox crashes with EXCEPTION_ACCESS_VIOLATION_READ at probably exploitable address
(Reporter)

Comment 1

5 years ago
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x134
(Reporter)

Comment 3

5 years ago
on firefox I find in crash stats that some crashes are more potentially exploitable like : 

https://crash-stats.mozilla.com/report/index/1ca305fb-cc09-4637-8c19-27c792120927
Crash Reason	EXCEPTION_ACCESS_VIOLATION_WRITE
Crash Address	0xffffffffbe832eff
-----------------------------------------------------------------------
or in tunderbird :
https://crash-stats.mozilla.com/report/index/b0a3cee0-0bc5-4cf3-9d50-3927e2120928
Crash Reason	EXCEPTION_ACCESS_VIOLATION_WRITE
Crash Address	0x149d9aa4
-----------------------------------------------------------------------
(Reporter)

Comment 4

5 years ago
https://crash-stats.mozilla.com/report/index/c4538389-6ed6-4461-9003-c3e192120926
Crash Reason	EXCEPTION_ACCESS_VIOLATION_EXEC
Crash Address	0x690ef317
(Reporter)

Updated

5 years ago
Sounds like this could be a test case for bug 776497.

Crashing on this line:
sfink@97589 1999      xpc_UnmarkGrayObject(currentInner->mJSObject);
Component: Untriaged → DOM
Keywords: crash, regressionwindow-wanted
Product: Firefox → Core
Blocks: 776497
(that line was added in bug 730208)
On an 18 debug build, it doesn't crash, it just trundles along for a while then produces this:

* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "'[JavaScript Error: "too much recursion" {file: "file:///Users/amccreight/mz/cent1/obj-dbg/dist/NightlyDebug.app/Contents/MacOS/components/nsUrlClassifierLib.js" line: 1844}]' when calling method: [nsITimerCallback::notify]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0"  data: yes]

Whereupon it seems to just sit there for a while.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Firefox 15.0.1 crash probably exploitable using window.showModalDialog() → Firefox 15.0.1 crash using window.showModalDialog()
Group: core-security
It would be great if somebody could look at this, as it might help fix a top crasher...
So, null pointer crash + offset ?
That's what it looks like.

It looks like the test case opens 10,000 modal dialogues, with the size doubling every time.
(Reporter)

Comment 11

5 years ago
Comment on attachment 665838 [details]
showModalDialogcrash.htm

><body onload="javascript:crash();"></body>
><script>
>function crash() {
>var string1 = unescape("%u0000%udead");
>for (i =0;i<10000;i++) {
>string1+=string1+string1;
>window.showModalDialog(string1, string1, "dialogHeight:300px; dialogLeft:200px;");
>}
>}
></script>
Attachment #665838 - Attachment mime type: text/plain → text/html
Keywords: csec-oom

Updated

5 years ago
Severity: normal → critical
Crash Signature: [@ nsGlobalWindow::SetNewDocument(nsIDocument*, nsISupports*, bool)]

Comment 12

5 years ago
Mozilla/5.0 (Windows NT 6.1; rv:22.0) Gecko/20100101 Firefox/22.0
Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20100101 Firefox/23.0
Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20130716 Firefox/24.0
Mozilla/5.0 (Windows NT 6.1; rv:25.0) Gecko/20130716 Firefox/25.0

In Socorro, there are couple of crashes with this signature in the last month: http://goo.gl/Qrxu3

When using the attached testcase with Firefox 22.0 (Build ID: 20130618035212), Firefox 23 beta 6 (Build ID: 20130715155216), Aurora 24.0a2 (Build ID: 20130716004006) and Nightly 25.0a1 (Build ID: 20130716030202), and the following steps:
1. Launch Firefox and open the testcase.
2. Click OK button in the 'Confirm dialog preference' pop-up.
3. Click on Options and 'Allow pop-ups for bug795248.bugzilla.mozilla.org'.
4. Refresh page.

Results at step 2: no crashes and in error console I get: 
NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMWindow.showModalDialog] @ https://bug795248.bugzilla.mozilla.org/attachment.cgi?id=665838:7

Results at step 4: the builds hang and in error console I get:
Error: [Exception... "'InternalError: too much recursion' when calling method: [nsITimerCallback::notify]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0"  data: no] 

Although, if at step 2 I click Cancel button, I got an intermittent crash:
 - for latest Aurora and FF 23 beta 6: mozalloc_abort(char const* const) | NS_DebugBreak | AppendUTF16toUTF8(nsAString_internal const&, nsACString_internal&) signature
 - for latest Nightly: mozalloc_abort(char const* const) | NS_DebugBreak | nsACString_internal::SetLength(unsigned int) signature

Any thoughts?
(In reply to Alexandra Lucinet [QA] from comment #12)
> Any thoughts?

It sounds like that jives with what mccr8 described in comment 7, modulo the intermittent crash. I bet the intermittent crash will be fixed by bug 732665.
Depends on: 732665

Comment 14

5 years ago
Based on comment 13, I'm removing the regressionwindow-wanted keyword. If anyone thinks otherwise, please add back the keyword and I'll look for the regression range.
Keywords: regressionwindow-wanted

Updated

2 years ago
Crash Signature: [@ nsGlobalWindow::SetNewDocument(nsIDocument*, nsISupports*, bool)] → [@ nsGlobalWindow::SetNewDocument(nsIDocument*, nsISupports*, bool)] [@ nsGlobalWindow::SetNewDocument]
Crash volume for signature 'nsGlobalWindow::SetNewDocument':
 - nightly(version 50):0 crashes from 2016-06-06.
 - aurora (version 49):0 crashes from 2016-06-07.
 - beta   (version 48):3 crashes from 2016-06-06.
 - release(version 47):37 crashes from 2016-05-31.
 - esr    (version 45):3 crashes from 2016-04-07.

Crash volume on the last weeks:
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       0       0       0       0       0       0       0
 - aurora        0       0       0       0       0       0       0
 - beta          1       1       0       0       0       0       1
 - release       4       4       4       8       4       3       5
 - esr           1       0       0       1       0       0       0

Affected platforms: Windows, Linux
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox-esr45: --- → affected
You need to log in before you can comment on or make changes to this bug.