Closed Bug 299209 (CVE-2005-2114) Opened 19 years ago Closed 19 years ago

anonymous function expression statement => JS stack overflow [crash in js3250.dll + (0002c7d4)]

Categories

(Core :: JavaScript Engine, defect, P2)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8beta3

People

(Reporter: chofmann, Assigned: brendan)

References

(
URL
)

Details

(Keywords: fixed-aviary1.0.5, fixed1.7.9, js1.5, Whiteboard: [sg:fix] scrub last attachment before disclosing, see comment 20)

Attachments

(1 file)

fix
1.85 KB, patch
shaver
: review+
jay
: approval-aviary1.0.5+
jay
: approval1.7.9+
brendan
: approval1.8b3+
Details | Diff | Splinter Review 
full disclosure deinal of service crash reported to security

evilninja wrote: 
> > Kurczaba Associates Advisories schrieb: 
> > >> >>Date Discovered: June 14, 2005 


here is all that I was able to get out of talback...

Incident ID: 7098019
Stack Signature	js3250.dll + 0x2c7d4 (0x6010c7d4) e08bd997
Email Address	chofmann@mozilla.org
Product ID	FirefoxTrunk
Build ID	2005062806
Trigger Time	2005-06-29 20:08:16.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	js3250.dll + (0002c7d4)

Since Last Crash	29061 sec
Total Uptime	29061 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
js3250.dll + 0x2c7d4 (0x6010c7d4)
mail from Paul Kurczaba 
paul at kurczaba.com

Mozilla Team,

We have found a security vulnerability that affects the following Mozilla
applications:
-Mozilla 1.7.8
-Firefox 1.0.4
-Camino 0.8.4

Details:
By using a specially crafted JavaScript function, it is possible to crash the
above named browsers. The script can be executed both with and without user
intervention.

The JavaScript Code:
The following Javascript code is what causes the browsers to crash:

for (a = 0; a <= 10000; a++)
{
   function(){("");}
}

Proof of Concept:
A proof-of-concept example of this vulnerability can be found at:
http://www.kurczaba.com/html/security/unpublished/crash_mozilla.htm

Credit:
Paul and Arnie Kurczaba

This is a very old bug -- it dates to ECMA-262 Edition 3 work in 1999.  It's not
exploitable.  I'll fix tomorrow.

/be
Assignee: general → brendan
Flags: blocking-aviary1.1+
Keywords: js1.5
Priority: -- → P2
Target Milestone: --- → mozilla1.8beta3
Summary: crash in js3250.dll + (0002c7d4) → anonymous function expression statement => JS stack overflow [crash in js3250.dll + (0002c7d4)]
Checking in regress-299209.js;
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-299209.js,v  <--  regress-299209.js
initial revision: 1.1
Flags: testcase+
Timeless was looking into this today as well, and some guy came on IRC claiming
it was exploitable but offered no demonstration.
(In reply to comment #4)
> Timeless was looking into this today as well, and some guy came on IRC claiming
> it was exploitable but offered no demonstration.

That's nice.

It's a JS interpreter stack overflow.  There's no way to forge object references
from script, so I doubt this IRC claim.  Reading garbage from beyond the current
stack chunk might lead to crashes, but not to controlled execution.

/be
Writing beyond the current stack chunk might corrupt the malloc heap.  That's
not inherently exploitable AFAIK.

If someone (jackerror on IRC is working on it) does come up with an exploit,
please mail me and dveditz@cruzio.com, or even the security-group@mozilla.org
mailing list, so we can mark this bug "security sensitive" to restrict access to
it, *then* the exploit can be attached to this bug, and we can award a bounty to
the person demonstrating the exploit.

/be
Attached patch fix — — Splinter Review 
Simple and direct.

/be
Attachment #187857 - Flags: review?
Attachment #187857 - Flags: approval1.8b3+
Fixed on trunk.  Fix is needed on the branches too.

/be
Status: NEW → RESOLVED
Closed: 19 years ago
Flags: blocking1.7.9?
Flags: blocking-aviary1.0.5?
Resolution: --- → FIXED
Flags: blocking1.7.9?
Flags: blocking1.7.9+
Flags: blocking-aviary1.0.5?
Flags: blocking-aviary1.0.5+
Comment on attachment 187857 [details] [diff] [review]
fix

Brendan, let's get this checked in on the branches as well. a=jay
Attachment #187857 - Flags: approval1.7.9+
Attachment #187857 - Flags: approval-aviary1.0.5+
Checked appropriately back-ported patch into branches.

/be
Keywords: fixed-aviary1.0.5, fixed1.7.9
syntax error on trunk and 1.0.5 and no crash.
Error: syntax error
Source File: http://www.kurczaba.com/html/security/unpublished/crash_mozilla.htm
Line: 48, Column: 11
Source Code:
			function(){};
Status: RESOLVED → VERIFIED
updated test to reflect expected syntax error
Checking in regress-299209.js;
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-299209.js,v  <--  regress-299209.js
new revision: 1.2; previous revision: 1.1
done

Bob, your new test doesn't crash without the patch. You have to eval() the 
complete for loop.
(In reply to comment #14)

Erik, thanks. I tested it and saw a crash in 1.0.4 but must have executed the
old version from the cache. fscking firefox cache. 

Checking in regress-299209.js;
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-299209.js,v  <--  regress-299209.js
new revision: 1.3; previous revision: 1.2
done

really fixed this time. new revision: 1.4; previous revision: 1.3

this causes the following failures in the js test suite:

ecma_3/Statements/regress-194364.js: sections 1, 3, 5, 7, 9
js1_5/Regress/regress-224956.js: section 29

was that intentional and the tests need to be changed?
(In reply to comment #17)
> this causes the following failures in the js test suite:
> 
> ecma_3/Statements/regress-194364.js: sections 1, 3, 5, 7, 9
> js1_5/Regress/regress-224956.js: section 29
> 
> was that intentional and the tests need to be changed?

From ECMA-262 Edition 3, 12.4:

12.4 Expression Statement

Syntax
ExpressionStatement : [lookahead not in {{, function}] Expression ;

Note that an ExpressionStatement cannot start with an opening curly brace
because that might make it ambiguous with a Block. Also, an ExpressionStatement
cannot start with the function keyword because that might make it ambiguous with
a FunctionDeclaration.

/be
Marking security sensitive because we have been sent a testcase that proves this
is exploitable.
Group: security
Sauron (jackerror on IRC) contacted me last week about this bug, and worked
hard to develop an exploit.  I recommend he get a bug bounty for his work, and
I would like to encourage him to file other security-sensitive bugs with
bugzilla.mozilla.org as soon as possible, so he can claim priority and win more
bounties.  He asked that I include his wishes here:

----- begin quote -----
Brendan,

Yes you can attach the exploitation.txt to the bug, Yes I have a bugzilla login
(sauron@nerim.net).  As I told to Daniel Veditz, I don't want the exploit to be
made public at anytime, even when a fixed version of mozilla will be available.
The bug take time to exploit because it is located in some part of the code one
as to take the time to understand before being able to do anything. Probably
nobody will code such an exploit and make it public, and I don't want mine to
be made public, I hate to provide destructive tools to clueless people who will
use it to annoy OpenSource users whose main purpose is not security.

Anyway, please can you just put a note about this when attaching the file to
the bug in the bugzilla ?

Thanks
-----end quote-----

I'm not sure how to arrange to *never* disclose his exploit without never
removing the security-sensitive flag from this bug, or else stripping this
attachment via bugzilla database hacks behind the scenes, before removing the
access restriction on this bug.  I'll leave it to dveditz to negotiate a
mutually satisfactory solution with sauron.

/be
*** Bug 299816 has been marked as a duplicate of this bug. ***
Blocks: 299816
Adding distributors
Whiteboard: [sg:fix]
*** Bug 300955 has been marked as a duplicate of this bug. ***
Whiteboard: [sg:fix] → [sg:fix] [scrub last attachment before disclosing]
Dan,

Is there a reason there is no Mozilla Foundation Security advisory for this issue?
Josh: see the status whiteboard.

/be
Do we need to open this bug to issue an advisory?  We often embargo bug details,
and say so in the advisory text.
Brendan,

I understand we have to scrub the attachment, but it's not uncommon to release
an MFSA without opening up the bug until a later date.
Additionally, this issue is CAN-2005-2114.  MITRE has it classified as simply a
DoS right now.  When this issue goes public I'll make sure they update their
description.
Josh: oh, sorry -- then dveditz should comment, since he updates the known
vulnerabilities page.

/be
Checking in ecma_3/Statements/regress-194364.js;
/cvsroot/mozilla/js/tests/ecma_3/Statements/regress-194364.js,v  <-- 
regress-194364.js
new revision: 1.4; previous revision: 1.3
done
Checking in js1_5/Regress/regress-224956.js;
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-224956.js,v  <--  regress-224956.js
new revision: 1.7; previous revision: 1.6
done

Are there any plans to open this bug up to the public?
No. there should be no such plans. not without removing at least the attachment.

comment 20 is perfectly clear on that point.
Group: security
Whiteboard: [sg:fix] [scrub last attachment before disclosing] → [sg:fix] scrub last attachment before disclosing, see comment 20
This appears to be CVE-2005-2114
Alias: CVE-2005-2114
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: