W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > March 2011

[Bug 12101] "Structured clone" can be passed an object with a hostile getter that returns an object identical to itself; "structured clone" does not prevent such an infinite regression.

From: <bugzilla@jessica.w3.org>
Date: Mon, 07 Mar 2011 21:03:09 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Pwha9-0004jV-RN@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12101

Allen Wirfs-Brock <allen@wirfs-brock.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allen@wirfs-brock.com

--- Comment #1 from Allen Wirfs-Brock <allen@wirfs-brock.com> 2011-03-07 21:03:09 UTC ---
I don't understand the issue here. Or perhaps the bug title is just misleading.

How is:

var circular1= { };
circular1.self = circular1;

any different from:

var circular = {get self() {return circular}};

from the perspective of the structured cloning algorithm?

In both cases the top level innovation of the algorithm will capture the
reference to the top level object in memory and the recursive call will
immediately return that reference.

A more problematic case would seem to be:

function makeAnother() {
   return Object.create(Object.prototype,
        {another:{get: makeAnother, enumerable: true}});}
var infinite = makeAnother();

This produces a lazily constructed infinite chain of objects. Applying the
structure clone algorithm should fairly quickly cause  resource exhaustion,
either space or time.  This is exactly what happens in current browsers (I
tested Safari 5 and FF4, btw FF produces the error much quicker than Safari) if
you do:

JSON.stringify(infinite)

>From a resource consumption perspective this problem is essentially no
different from accessors like:

var loop = {get prop () {while(true);};
var recur = {get prop () {function r() {return r()}; r()}};
var blowheap = {get prop () {var a=[]; while (true) a.push(new Object)}};

Essentially, anytime a Web App API calls back into JavaScript (or any other
language) user supplied code there is the possibility that the call back will
not terminate or have some other resource consumption failure or the sort that
can routinely occur in in script code.  Accessors are such call-backs. Web App
specs. are going to have to deal with them either implicitly or explicitly.

The reasonable fix would seem to be to make sure that such call backs only
occur at points where such failures can be reasonably dealt with. Either that
or explicitly ignore accessors.  This solution may be acceptable for some uses
of structured clone but probably isn't reasonable for all arbitrary object
property value accesses in all web app APIs.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 7 March 2011 21:03:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 March 2011 21:03:15 GMT