Last Comment Bug 355069 - Bantown discusses an arbitrary code execution in the JavaScript implementation on any OS
: Bantown discusses an arbitrary code execution in the JavaScript implementatio...
Status: RESOLVED WORKSFORME
:
Product: Core
Classification: Components
Component: General (show other bugs)
: 1.8 Branch
: All All
: -- critical (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-01 14:06 PDT by Bantown Snitch
Modified: 2010-02-16 13:16 PST (History)
47 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
relevant slides from powerpoint presentation (1.49 KB, text/plain; charset=utf-8)
2006-10-01 14:52 PDT, David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch)
no flags Details
transcript from the talk (1.43 KB, text/plain)
2006-10-02 01:43 PDT, Jesse Ruderman
no flags Details
transcript from the talk (1.47 KB, text/html)
2006-10-02 02:02 PDT, Jesse Ruderman
no flags Details
original source [hangs/crashes browser] (1.82 KB, text/html)
2006-10-02 18:32 PDT, Daniel Veditz [:dveditz]
no flags Details
core.js for posterity (22.61 KB, text/plain)
2006-10-02 18:35 PDT, Brendan Eich [:brendan]
no flags Details
dom.js for posterity (19.38 KB, text/plain)
2006-10-02 18:35 PDT, Brendan Eich [:brendan]
no flags Details

Description Bantown Snitch 2006-10-01 14:06:23 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3

At LULZCON (see encyclodpedia dramatica) Bantown members discussed a bug found relating how javascript is handled/executed in all tested versions of firefox. Bantown specifically plans not to release the exploit but plans to exploit it.

So all the information I have is that one can execute arbitrary code in firefox via javascript.


See the post and slides at:
http://hepkitten.livejournal.com/513183.html

Reproducible: Always
Comment 1 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2006-10-01 14:41:00 PDT
No reason having this security-sensitive if it's just a link to a public blog.
Comment 2 Thor Larholm 2006-10-01 14:47:48 PDT
The link to the PowerPoint presentation (which supposedly has slides of the exploit) is completely dead. Are there any backup links for this? If not, there's not really any useful information on this LiveJournal entry.
Comment 3 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2006-10-01 14:52:17 PDT
Created attachment 240851 [details]
relevant slides from powerpoint presentation

The powerpoint presentation was still up when I read it, and I have a copy.  (It's 1.7MB, so I can't attach it.)

But here's the text of the relevant 4 slides.
Comment 4 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2006-10-01 15:28:01 PDT
As far as I can tell, all the code snippet provided does (in my 1.8 branch debug build) is fill up lots of memory.  Presumably, there's more code not shown.

Anybody know if the slides in question claiming to report a stack overflow or a stack buffer overrun?
Comment 5 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-10-01 15:53:33 PDT
(In reply to comment #4)
> As far as I can tell, all the code snippet provided does (in my 1.8 branch
> debug build) is fill up lots of memory.  Presumably, there's more code not
> shown.
> 
> Anybody know if the slides in question claiming to report a stack overflow or a
> stack buffer overrun?

None of the code after
         for (var j = 0; j < 300; j++)
            hezbstr += hezbstr; 
can ever execute...
Comment 6 Thor Larholm 2006-10-01 15:58:14 PDT
I did get a crash on my first run, with dbg set to false, no attached debugger, creating a new object and calling it's hello method, but that could just as easily be an ordinary crash bug. No crashes or exceptions on subsequent runs, with or without a debugger attached.
Comment 7 Jesse Ruderman 2006-10-02 01:30:52 PDT
One possibility (pointed out by Window) is that the script fills up memory, and there's an OOM crash somewhere.  I don't think that's the case, because doubling a string over and over is more likely to result in a single failed huge allocation than exhausting virtual memory.  But we could test for that, either by limiting how much memory Firefox is allowed to use (with |ulimit|?), or by testing on a 32-bit machine with enough RAM to not swap.

Another possibility, which I think is more likely based on the descriptions given by the presenters, is that there is some kind of "re-entrancy" in the JavaScript engine.  We already know that the JavaScript engine violates run-to-completion in bug 355097 and bug 52209.

jst, do you think this could be a result of bug 52209?

I don't understand how that would be connected to a "clever recursion trick" that lets you "fill the stack", though.  There are ways around JavaScript's recursion limits (e.g. bug 347157), but in any sane OS, a stack overflow is a safe segfault.
Comment 8 Jesse Ruderman 2006-10-02 01:43:18 PDT
Created attachment 240905 [details]
transcript from the talk

I transcribed this from the DVD of the presentation just now.
Comment 9 Jesse Ruderman 2006-10-02 02:02:07 PDT
Created attachment 240910 [details]
transcript from the talk

I hate bug 253564.
Comment 10 Igor Bukanov 2006-10-02 02:24:20 PDT
(In reply to comment #5)
> None of the code after
>          for (var j = 0; j < 300; j++)
>             hezbstr += hezbstr; 
> can ever execute...

Indeed. The example is either incomplete or can be replaced by:

Object.prototype.hello = function () {

    var wackyaddrs = unescape("%u0800%u0000%u1000%u0000%u2000%u0000%u4000%u0000");

    setTimeout(function () { var o = new Object (); o.hello(); }, 50);
    var hezbstr = dbg ? "loldongsloldongs!" + wackyaddrs : wackyaddrs;

    for (;;)
        hezbstr += hezbstr;
};

Then if there is a bug, then it is either an integer overflow when growing the string or in the timer implementation on low memory. 
Comment 11 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2006-10-02 11:13:02 PDT
(In reply to comment #7)
> huge allocation than exhausting virtual memory.  But we could test for that,
> either by limiting how much memory Firefox is allowed to use (with |ulimit|?),

FWIW, I did that yesterday on Linux (ulimit -v 750000), and I ended up crashing after quite a few "Javascript error: out of memory" due to new throwing (bug 324005).
Comment 12 Brendan Eich [:brendan] 2006-10-02 12:00:58 PDT
(In reply to comment #10)
> Then if there is a bug, then it is either an integer overflow when growing the
> string

All JS string concats funnel through js_ConcatStrings, and since string length is bounded to 2^30 - 1, the allocation or reallocation there should not be able to overflow.

> or in the timer implementation on low memory. 

This is something to focus on.

/be
Comment 13 Brendan Eich [:brendan] 2006-10-02 12:12:37 PDT
(In reply to comment #7)
> Another possibility, which I think is more likely based on the descriptions
> given by the presenters, is that there is some kind of "re-entrancy" in the
> JavaScript engine.  We already know that the JavaScript engine violates
> run-to-completion in bug 355097 and bug 52209.

It's not the JS engine, of course, that can violate run to completion.  It is the DOM embedding code, or other code in Gecko.  In a single (main) thread, the run-to-completion model can be subverted by any native method implementation, e.g. for a modal dialog function (alert/confirm/prompt).

The transcript shows cargo-cult science knowledge of JS ("threads", etc.), but you're right to smell something wrong here.  When I created JS in Netscape 2, I intentionally implemented run to completion as the execution model.  This meant that timeouts would defer while a modal dialog was flying.  Netscape 2-4, IE all versions, Safar, and Opera all follow this rule.  Mozilla does not.  Example:

data:text/html,<script>var i=0;function f(d){d.getElementById('t').value = ++i;}</script><body onload="setInterval(f, 1000, document)"><button onclick="prompt('foo')">click me</button><input id="t" size="4"></body>

Click on the "click me" button and let the prompt stay up; watch the text field show the counter incrementing.

/be
Comment 14 Brendan Eich [:brendan] 2006-10-02 13:19:53 PDT
(In reply to comment #13)
> This meant
> that timeouts would defer while a modal dialog was flying.  Netscape 2-4, IE
> all versions, Safari, and Opera all follow this rule.  Mozilla does not. 
> Example:
> 
> data:text/html,<script>var i=0;function f(d){d.getElementById('t').value =
> ++i;}</script><body onload="setInterval(f, 1000, document)"><button
> onclick="prompt('foo')">click me</button><input id="t" size="4"></body>
> 
> Click on the "click me" button and let the prompt stay up; watch the text field
> show the counter incrementing.

This is bug 279518 at least (mark dups if you can identify true duplicates).

/be
Comment 15 Daniel Veditz [:dveditz] 2006-10-02 18:32:36 PDT
Created attachment 241005 [details]
original source [hangs/crashes browser]

Here's the full testcase from Mischa (via e-mail to Window). He didn't make any attempt to clean out extraneous cruft that accrued during development, this is the full raw testcase.

(the original sourced "js/core.js" and "js/dom.js", not sure which version specifically but presumably the current six-apart ones. Since they're utility libraries it probably doesn't matter much.)
Comment 16 Brendan Eich [:brendan] 2006-10-02 18:35:13 PDT
Created attachment 241006 [details]
core.js for posterity
Comment 17 Brendan Eich [:brendan] 2006-10-02 18:35:54 PDT
Created attachment 241007 [details]
dom.js for posterity
Comment 18 Jesse Ruderman 2006-10-02 19:14:45 PDT
In addition to the "setTimeout during alert" issue (bug 52209 and bug 279518), this testcase might be taking advantage of bug 324149, "Moving into an alert dialog sends a mousemove event".
Comment 20 georgi - hopefully not receiving bugspam 2006-10-03 02:10:18 PDT
(In reply to comment #12)
> 
> All JS string concats funnel through js_ConcatStrings, and since string length
> is bounded to 2^30 - 1, the allocation or reallocation there should not be able
> to overflow.
> 

if you manage to reach this bound, i.e. String.length== 2^30 -1, byte size 2G off by few bytes, i suspect you are already in trouble. actually even 2^30 - 5 may do iirc. the best i could do was about *around* 2^30 - 2^20. so please give the largest js string you can construct in any away on a 32 bit os.

suggest trying this testcase in a release build, because there some things are noops.

Comment 21 georgi - hopefully not receiving bugspam 2006-10-03 04:58:01 PDT
(In reply to comment #20)
ooops, this comment was total sh*t, don't take it seriously.
Comment 22 Tanner M. Young [:tmyoung] 2009-07-23 17:16:10 PDT
Is this crash still reproducible in Firefox 3.5?  If it isn't, we should resolve it as RESOLVED WORKSFORME.
Comment 23 Nickolay_Ponomarev 2010-02-16 13:16:47 PST
Since no-one replied to Tanner, the last comment linked to a post saying there actually was no vulnerability here, and the testcase doesn't appear to have any effect on the browser, I hope I won't get yelled at for closing this one :)

Note You need to log in before you can comment on or make changes to this bug.