458679 - (CVE-2008-5502) Crash [@ js_DeflateString]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: crash log

function f()
{
  for (var i = 1; i < dps.length; ++i) {
    var a = "";
    var b = "";
    var c = "";
  }
}

function stringOfLength(n)
{
  if (n == 0) {
    return "";
  } else if (n == 1) {
    return "\"";
  } else {
    var r = n % 2;
    var d = (n - r) / 2;
    var y = stringOfLength(d);
    return y + y + stringOfLength(r);
  }    
}


this.__defineGetter__('x', this.toSource);
while (x.length < 12000000) { 
  let q = x;
  s = q + q; 
}
print(x.length);
<e4x>{x}</e4x>;


Huge thanks to Jesse Ruderman for helping to reduce this massive testcase. These lines crash js trunk shell at 0x0000000006b30000.

This also asserts debug shell at "Assertion failure: nbytes != 0, at jsapi.cpp:1841". Related to bug 421623 or bug 457521?

Nominating security sensitive because they crash at this scary address. Nominating wanted-1.9.0.x as well because we have seen variants of this testcase crashing 1.9.0.x.

Comment 1

[Igor Bukanov]

Here is a simplified test case:

~/m/31-ff/js/src $ cat ~/s/x.js
var x = "<";

while (x.length < 12000000)
    x += x;

<e4x>{x}</e4x>;
~/m/31-ff/js/src $ ./Linux_All_DBG.OBJ/js ~/s/x.js
segmentation fault

The reason for the bug is that GetXMLEntity assumes that FastAppendChar is infallible and continues to read characters from the buffer.

Comment 2

[Igor Bukanov]

Attachment: fix v1

The patch adds checks to GetXMLEntity to verify that the string buffer state after each FastAppendChar.

Comment 3

[Igor Bukanov]

Attachment: fix v2

The new version has stricter assert for error reporting in GetXMLEntity.

Comment 4

[Igor Bukanov]

landed - http://hg.mozilla.org/mozilla-central/rev/f7838da9f1a8

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: patch for 1.9.0.x

Patch portage to Gecko 1.9.0.x.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: patch for 1.8.1.x

Patch portage for 1.8.1.x

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: diff between trunk and both patches

Here's a diff of the backported patches against the trunk patch to hopefully prevent more bad backports..

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

note: I did the |cvs diff| from the js/src/ directory..

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

The testcase in comment #0 / comment #1 applies only to the trunk, for the testsuite. They are not branch testcases.

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 343521 [details] [diff] [review]
patch for 1.9.0.x

Since there's no verification testcase for the branches we're nervous taking this at the end of the cycle. Maybe next time.

Comment 11

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I've discovered a 1.9.0.x testcase that crashes at js_DeflateString (not an easy one to find, required lots of CPU time) which I've just sent to Jesse for further reduction. Will comment when it's done.

Comment 12

[Jesse Ruderman]

Attachment: 1.9.0.x testcase

This crashes my 1.9.0.x debug js shell.

Comment 13

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: patch for 1.9.0.x - v2

This one applies cleanly and resolves the crash. The shell now shows "typein:17: InternalError: script stack space quota is exhausted" instead of crashing. Bringing over review. Re-requesting approval1.9.0.4 now that the testcase is found.

Comment 14

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

diff for 1.9.0.x patch v2:

$ diff getxml_entity_458679.patch patch-v2.diff 
1c1
< Index: 31-ff/js/src/jsscan.cpp
---
> Index: js/src/jsscan.c
3,5c3,8
< --- 31-ff.orig/js/src/jsscan.cpp	2008-10-06 13:45:09.000000000 +0200
< +++ 31-ff/js/src/jsscan.cpp	2008-10-06 13:53:30.000000000 +0200
< @@ -809,23 +809,27 @@ GetXMLEntity(JSContext *cx, JSTokenStrea
---
> RCS file: /cvsroot/mozilla/js/src/jsscan.c,v
> retrieving revision 3.147
> diff -u -8 -p -r3.147 jsscan.c
> --- js/src/jsscan.c	4 Aug 2008 20:51:34 -0000	3.147
> +++ js/src/jsscan.c	19 Oct 2008 05:39:40 -0000
> @@ -808,23 +808,27 @@ GetXMLEntity(JSContext *cx, JSTokenStrea
33c36
< @@ -901,16 +905,18 @@ GetXMLEntity(JSContext *cx, JSTokenStrea
---
> @@ -900,16 +904,18 @@ GetXMLEntity(JSContext *cx, JSTokenStrea

Comment 15

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Comment on attachment 343521 [details] [diff] [review]
patch for 1.9.0.x

review+ brought over to updated patch.

Comment 16

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Comment on attachment 343522 [details] [diff] [review]
patch for 1.8.1.x

More comprehensive testing showed 1.8.1.x branch isn't affected by this at all - obsoleting patch. The shell works as expected.

Comment 17

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Updating flags and nominating blocking1.9.0.4? due to discovery of 1.9.0.x branch testcase.

Comment 18

[Daniel Veditz [:dveditz]]

Comment on attachment 343776 [details] [diff] [review]
patch for 1.9.0.x - v2

Would you mind getting an independent review on the port -- we don't want any bad branch merges and there are some differences in the branch version of the engine that might have hidden implications. Either Igor or Brian is fine.

We're closing down 1.9.0.4, so request approval on the next review.

Comment 19

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Comment on attachment 343776 [details] [diff] [review]
patch for 1.9.0.x - v2

Re-requesting review as requested.

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 343776 [details] [diff] [review]
patch for 1.9.0.x - v2

approved for 1.9.0.5, a=dveditz for release-drivers

(please watch tinderbox for the tree to open before landing)

Comment 21

[Igor Bukanov]

To Gary: will you land the 1.9.0.* patch? The code freeze for 1.9.0.5 is Monday, November 17 at 11:59pm PST.

Comment 22

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #21)
> To Gary: will you land the 1.9.0.* patch? The code freeze for 1.9.0.5 is
> Monday, November 17 at 11:59pm PST.

Igor, I'd love to, but I don't have commit access to js/

Comment 23

[Igor Bukanov]

I landed the patch from the comment 13 to 1.9.0 branch:

Checking in jsscan.c;
/cvsroot/mozilla/js/src/jsscan.c,v  <--  jsscan.c
new revision: 3.148; previous revision: 3.147
done

Comment 24

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

$ ./js-opt-moz190-intelmac 
js> var x = "<";
js> 
js> while (x.length < 12000000)
    x += x;

(lots of output spew containing "<")

js> 
js> <e4x>{x}</e4x>;
typein:6: InternalError: script stack space quota is exhausted
js> 


Now it shows the "InternalError: script stack space quota is exhausted" error message instead of crashing.

Thanks Igor! Verified.

Comment 25

[Bob Clary [:bc] (inactive)]

Igor, the InternalError: script stack space quota is exhausted is thrown for the test cases in 1.9.1 but not in 1.8.1. Is the exception expected on 1.9.1?

Comment 26

[Igor Bukanov]

(In reply to comment #25)
> Igor, the InternalError: script stack space quota is exhausted is thrown for
> the test cases in 1.9.1 but not in 1.8.1. Is the exception expected on 1.9.1?

The exception is expected on 1.9.* as the XML parser uses script stack quota space in 1.9.* and the space is limited to prevent DOS.

Comment 27

[Bob Clary [:bc] (inactive)]

Attachment: e4x/Regress/regress-458679-01.js

Comment 28

[Bob Clary [:bc] (inactive)]

Attachment: e4x/Regress/regress-458679-02.js

Comment 29

[Bob Clary [:bc] (inactive)]

Attachment: js1_7/extensions/regress-458679.js

Comment 30

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Bob, verified?

Comment 31

[Bob Clary [:bc] (inactive)]

(In reply to comment #29)
> Created an attachment (id=347845) [details]
> js1_7/extensions/regress-458679.js

This test appears to hang the browser but not the shell. Igor?

Comment 32

[Igor Bukanov]

(In reply to comment #31)
> This test appears to hang the browser but not the shell. Igor?

Hm, do you mean that the shell terminates with some out-of-something exception while browser simply hangs? If so, could try to capture a stack trace at some moment when the browser busy executing something?

Comment 33

[Bob Clary [:bc] (inactive)]

Attachment: Sample on Mac OS X

shell terminates normally with no error, browser hangs.

Comment 34

[Igor Bukanov]

(In reply to comment #33)
> Created an attachment (id=348218) [details]

Hm, how do I read this to get a stack trace?

Comment 35

[Jesse Ruderman]

It's a sample of a hang, so instead of a single stack trace, you see a tree representing hundreds of stack traces.

Comment 36

[Bob Clary [:bc] (inactive)]

Attachment: pstack output on centos5 32bit

Igor, is this any better?

Comment 37

[Bob Clary [:bc] (inactive)]

David, the not found test in bug 462939 is from this bug.

Comment 38

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

BC, can you verify this fix for 1.9.0.5?

Comment 39

[Bob Clary [:bc] (inactive)]

verified no crash 1.9.0.5 shell/browser e4x/Regress/regress-458679-01.js, e4x/Regress/regress-458679-02.js, no crash in shell/browser js1_7/extensions/regress-458679.js but the test does hang/timeout in the browser. testsed on mac os x 10.5, centos5, winxp

Comment 40

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #39)
> verified no crash 1.9.0.5 shell/browser e4x/Regress/regress-458679-01.js,
> e4x/Regress/regress-458679-02.js, no crash in shell/browser
> js1_7/extensions/regress-458679.js but the test does hang/timeout in the
> browser. testsed on mac os x 10.5, centos5, winxp

Bob, perhaps you should file the hang as a new bug for Igor?

Comment 41

[Bob Clary [:bc] (inactive)]

filed Bug 468058

Comment 42

[Bob Clary [:bc] (inactive)]

verified mozilla-central, tracemonkey

Comment 43

[Alexander Sack]

not for 1.8.0

Comment 44

[Bob Clary [:bc] (inactive)]

tests checked in http://hg.mozilla.org/mozilla-central/rev/98e0818f1bb4 as well as cvs.