651990 - (CVE-2011-2364) Investigate crash [@ js_TraceScript]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Brandon Sterne (:bsterne)]

Attachment: testcase2 (crashes 1.9.2)

The following was reported to security@m.o by [e-mail].  There are several crash signatures that were observed, but the worst looking one is the one in this bug's summary:
bp-f9041a36-322d-498e-b9bb-ef4142110419 (caused by testcase2)

There may be more than one bug here.  The rest of rh0's email follows:

------

Hello Brandon,

Thanks for your answer. The modified testcase is in the attachment "testcase2.html". There is even a third distinct crash when starting it.
This testcase led to the following crashes, which are to my opinion 3 distinct ones:

1) bp-f9041a36-322d-498e-b9bb-ef4142110419
2) bp-5b1be6ee-555a-403e-86eb-b49832110419
3) bp-e165af98-a78b-4cd8-9ffe-a07562110419
4) bp-0ab9cf70-d4c5-47a8-82a0-5a3702110419
5) bp-489b103c-f765-4684-8d31-5a30d2110419
6) bp-660b8d86-a0f3-4b34-b2a3-fe2952110419
7) bp-178d6ac7-c5a1-4e84-89bc-a82012110419
8) bp-1863f900-69b9-4a8d-9486-0343c2110419
9) bp-675e6d6f-58a8-4ffa-b719-8b4d12110419
10) bp-bbf19bc6-44fc-465e-bdcf-2cda22110419
11) bp-18b9c507-dbed-405e-beae-1a69d2110417
12) bp-348e681b-3315-4b1d-9b45-6902d2110417
13) bp-87858153-b8d1-44a7-b7e4-d74d02110417 (already inside last email)

Crash type A: 13),1) access violation execute
Crash type B: 9),8),4)
access violation read at 0x20
Crash type C: 12),11),10),7),6),5),3),2) access violation write at 0x0

Crash A is maybe the most dangerous one. Though i don't know exactly how to trigger all three differently.
Here are some scenarios i tried:
Load testcase -> switch on firebug -> crash
Switch on firebug -> load testcase -> sometimes a crash -> if no crash  occurs => access dom panel -> crash

I think the worst crash (type A) is mostly triggered when starting firefox again after the crash.
Sometimes it loads the tabs automatically which were opened in the last session, which leads to a new crash, as it tries to load the testcase aswell.
This is crash A. (Firebug is automatically switched on in this case)
Can this automatic reopening be set? (except in the general option tab "when firefox starts").

Please keep me informed. For bugzilla I use the address [e-mail].  As soon as the bug is
filed, can I access it over my account ? Please let me know if you need something else to proceed. I will still look if other similar testcases trigger the crashes more precisely and/or the issue can be triggered without firebug and/or exploited.

Thank you and regards,

Rh0

Comment 1

[Brandon Sterne (:bsterne)]

Attachment: testcase3

With Firebug installed, the reporter says he can reproduce the js_TraceScript crash reliably with testcase3, e.g.:
bp-0eb1e014-319a-4ad1-8f66-6283a2110419

-----
Hello Brandon,

with the following testcase (testcase3.html) I was able to trigger almost always the access execution violation, when trying the following several times
1) Open Firefox
2) double click testcase file (=> firefox loads testcase without crash)
3) click on firebug icon
4) after a period of hanging firebug appears in the bottom half without crashing
5) click anywhere in the firefox or firebug window or on a firebug panel (dom/script)
6) crash

Firebug was set to "On for All Web Pages" and was always in minimized mode.
If Firefox crashes at step 2 or 4 , it is the NULL pointer write attempt, otherwise almost always the access execution violation.

Crash IDs (access execution violation):

bp-0eb1e014-319a-4ad1-8f66-6283a2110419
bp-634099a5-0db6-440c-b0ac-2750e2110419
bp-4097dc7d-209f-4be5-b4ff-6bd302110419
bp-6759ffb8-e88e-400a-b4b9-529df2110419
bp-d6329b50-8071-4c32-8a2a-b43542110419

bp-aed1d101-5582-458c-bec0-7373b2110419
bp-91a4a992-e27e-4545-afce-baf182110419

I hope this helps and that this email and especially my last one are not too confusing or inconvenient to read.

Best regards,

Rh0

Comment 2

[Rh0]

In my testing the break condition in the 2nd for loop in testcase3 can be reduced from 16 (n <= 16) to 6 (n <= 6).
Then there is no hanging anymore in step 4, firebug appears immediately in the bottom half.
Then clicking the DOM panel of firebug (step 5) results in a hang period with a crash afterward (at js_TraceScript)

Rh0

Comment 3

[David Mandelin [:dmandelin]]

I tried to reproduce this, and I got it to crash once, with testcase3 I think, but when I tried to make it crash again so I could debug it, I couldn't get it to crash any more.

Comment 4

[Rh0]

(In reply to comment #3)
> I tried to reproduce this, and I got it to crash once, with testcase3 I think,
> but when I tried to make it crash again so I could debug it, I couldn't get it
> to crash any more.

With testcase3 (modified: comment 2) on WinXP SP3 (~2GB Ram assigned in VirtualBox OSE Version 3 ,Host: Debian 6.0) 8 of 10 crashes are at js_TraceScript. On native Windows Vista (2GB RAM)I observed "only" JSScope::add crashes (write attempt at 0x0)
bp-90443242-b019-4e49-9856-84a022110423
bp-a240c910-5d62-4343-8dd9-6a9d82110422
On a low hardware netbook (1GB RAM) with native Windows 7 it hangs for minutes but finally crashes (JSScope::add)
bp-3fa77111-719b-4d07-b183-6663f2110423
On Ubuntu 10.04 on VirtualBox (512MB RAM) i get a SIGKILL signal, no crash reporter comes up.
There's always a crash, after accessing the DOM Panel. If nothing "happens" clicking into the empty firefox window makes firefox unresponsive and ends with a crash.

Comment 5

[David Mandelin [:dmandelin]]

(In reply to comment #4)
> (In reply to comment #3)
> > I tried to reproduce this, and I got it to crash once, with testcase3 I think,
> > but when I tried to make it crash again so I could debug it, I couldn't get it
> > to crash any more.
> 
> With testcase3 (modified: comment 2) on WinXP SP3 (~2GB Ram assigned in
> VirtualBox OSE Version 3 ,Host: Debian 6.0) 8 of 10 crashes are at
> js_TraceScript. On native Windows Vista (2GB RAM)I observed "only" JSScope::add
> crashes (write attempt at 0x0)
> bp-3fa77111-719b-4d07-b183-6663f2110423
> bp-a240c910-5d62-4343-8dd9-6a9d82110422
> On a low hardware netbook (1GB RAM) with native Windows 7 it hangs for minutes
> but finally crashes (JSScope::add)
> bp-90443242-b019-4e49-9856-84a022110423
> On Ubuntu 10.04 on VirtualBox (512MB RAM) i get a SIGKILL signal, no crash
> reporter comes up.
> There's always a crash, after accessing the DOM Panel. If nothing "happens"
> clicking into the empty firefox window makes firefox unresponsive and ends with
> a crash.

Thanks for the reply. I was able to repro with the change. I'm fairly sure this particular instance is an OOM crash and not sg:critical. The invalid-exec crashes still concern me a bit. I think they are probably ultimately caused by OOMs as well, so maybe fixing the OOMs will fix those.

Comment 6

[Rh0]

To comment #5

I agree that the access violation read and access violation write are maybe not critical. According to https://wiki.mozilla.org/Security_Severity_Ratings I would consider at least the access execution violation as critical (execution of random memory). There are also fixed bugs, which were critical although they were OOM crashes (e.g.: 608336 , 583077 , 607160 ) So i think an OOM can still be critical. Please correct me if I am wrong.

Comment 7

[David Mandelin [:dmandelin]]

(In reply to comment #6)
> To comment #5
> 
> I agree that the access violation read and access violation write are maybe not
> critical. According to https://wiki.mozilla.org/Security_Severity_Ratings I
> would consider at least the access execution violation as critical (execution
> of random memory). There are also fixed bugs, which were critical although they
> were OOM crashes (e.g.: 608336 , 583077 , 607160 ) So i think an OOM can still
> be critical. Please correct me if I am wrong.

I agree with you. By "this instance", I meant the exact crash address + access type + source location that I crashed on. But the exec versions are sg:critical.

Comment 8

[David Mandelin [:dmandelin]]

Attachment: Patch

Comment 9

[Luke Wagner [:luke]]

Comment on attachment 528467 [details] [diff] [review]
Patch

Review of attachment 528467 [details] [diff] [review]:

::: js/src/jsobj.cpp
@@ +3054,5 @@
     size_t oslots = size_t(slots[-1]);
 
     slots = (jsval*) cx->realloc(slots - 1, nwords * sizeof(jsval));
+    if (!slots)
+        return false;

Hoooeee I'm using splinter to comment IN LINE.  r+

Comment 10

[David Mandelin [:dmandelin]]

Notes:

1. Fx4 is confirmed unaffected: it has the OOM check added by the patch.

2. I'm pretty sure there is a bug in Firebug being hit here, so that should probably be reported as well.

Comment 12

[Daniel Veditz [:dveditz]]

I don't see how this patch could possibly fix the EXCEPTION_ACCESS_VIOLATION_EXEC. In the old code where you didn't null-check slots you should immediately crash on the following line
     *slots++ = nslots;

I guess you aren't claiming it does, but then we can't say "Fx4 is confirmed unaffected" based on it having this null check. We can only say Fx4 is not susceptible to the patched crash, which doesn't look like it matches any of the signatures that Rh01 is reporting.

Comment 13

[David Mandelin [:dmandelin]]

(In reply to comment #12)
> I don't see how this patch could possibly fix the
> EXCEPTION_ACCESS_VIOLATION_EXEC. In the old code where you didn't null-check
> slots you should immediately crash on the following line
>      *slots++ = nslots;
> 
> I guess you aren't claiming it does, but then we can't say "Fx4 is confirmed
> unaffected" based on it having this null check. We can only say Fx4 is not
> susceptible to the patched crash, which doesn't look like it matches any of the
> signatures that Rh01 is reporting.

Then there are probably multiple bugs here. The patch for the one I was able to repro, using testcase3.html modified per comment 2. It seems likely that we could OOM in various places and fail to detect that, leading to different crash signatures. I will see if I can reproduce the exec violation crash myself.

Comment 14

[David Mandelin [:dmandelin]]

(In reply to comment #13)
> (In reply to comment #12)
> > I don't see how this patch could possibly fix the
> > EXCEPTION_ACCESS_VIOLATION_EXEC. In the old code where you didn't null-check
> > slots you should immediately crash on the following line
> >      *slots++ = nslots;
> > 
> > I guess you aren't claiming it does, but then we can't say "Fx4 is confirmed
> > unaffected" based on it having this null check. We can only say Fx4 is not
> > susceptible to the patched crash, which doesn't look like it matches any of the
> > signatures that Rh01 is reporting.
> 
> Then there are probably multiple bugs here. The patch for the one I was able to
> repro, using testcase3.html modified per comment 2. It seems likely that we
> could OOM in various places and fail to detect that, leading to different crash
> signatures. I will see if I can reproduce the exec violation crash myself.

I can't get any of the test cases to crash with my patch applied. It clearly fixes a bug, so I'd like to land that, then let rh01 test again and see if there's anything left.

Comment 15

[Rh0]

(In reply to comment #10)
> Notes:
> 
> 1. Fx4 is confirmed unaffected: it has the OOM check added by the patch.
> 
> 2. I'm pretty sure there is a bug in Firebug being hit here, so that should
> probably be reported as well.

To 1.:
There is another issue related to this here, but it affects not only the 1.9.2 but also the 2.0 branch of mozilla firefox, so I filed it as new bug: bug 654002

To 2.:
I reported this issue also as firebug problem: http://code.google.com/p/fbug/issues/detail?id=4410

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 528467 [details] [diff] [review]
Patch

Approved for 1.9.2.18, a=dveditz for release-drivers

Comment 17

[David Mandelin [:dmandelin]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/334474ffaced

Comment 18

[Johnny Stenback (:jst)]

This is fixed now then.

Comment 19

[Rh0]

I just realized i could use the nightly builds. I tested 3.6.18pre:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/firefox-3.6.18pre.en-US.win32.installer.exe
and got to crash it once at all, but at js_TraceScript:
bp-9ff2cf31-25b6-48bb-9b52-308c92110519

Comment 20

[chris hofmann]

bc, can you run the crash automation over the test scripts here with both 3.6.17 or before, and also latest 3.6.18 under the following:

 1) no firefug
 2) firebug installed but not running
 3) firebug installed and running

to see if we can get some consistent results.

If there is a consistent crash that's exploitable still we need to stay on this bug or open up new ones.

then we probably need to do the same testing with mozilla-central builds related to bug 654002.

tomcat if you can test by hand that might also help to answer some of these questions.

Comment 21

[Bob Clary [:bc] (inactive)]

The crash automation can't handle the str for interacting with firebug unfortunately.

Comment 22

[Carsten Book [:Tomcat]]

(In reply to comment #20)

> tomcat if you can test by hand that might also help to answer some of these
> questions.

yeah will look into this!

Comment 23

[Al Billings [:abillings - ex-MoCo]]

This is verified fixed in 1.9.2.

Using testcase 3 with Firefox 3.6.17 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 (.NET CLR 3.5.30729)) on XP SP3 with Firebug 1.6.2, I get a crash when selecting the DOM tab (https://crash-stats.mozilla.com/report/index/b15793b4-4983-40ad-95c6-2fd512110607). The same goes for a crash in testcase 3 (https://crash-stats.mozilla.com/report/index/230b58a7-a341-4fbb-bade-e41572110607).

With last night's 1.9.2.18pre build, I get neither crash (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18pre) Gecko/20110607 Namoroka/3.6.18pre (.NET CLR 3.5.30729)).

Comment 24

[Daniel Veditz [:dveditz]]

comment 23 conflicts with comment 19

Comment 27

[Raymond Forbes[:rforbes]]

rforbes-bugspam-for-setting-that-bounty-flag-20130719