`free` operator

David Bruant bruant.d at gmail.com
Sat Oct 27 04:22:49 PDT 2012


2012/10/26 Isaac Schlueter <i at izs.me>

> (...)
>

We've got some band-aids in place in the node http.js file to prevent
> parser leaks.  A more forcible free() method would have made it much
> easier.  The long-term solution is to rewrite the program (...)

So you're suggesting that a language-level feature with abusive authority
introducing use-after-free bugs (and maybe others) should be included to
solve short-term problems?



> Yehuda's "action at a distance" complaint is definitely a valid
> concern.  However, note that an object can't be freed unless you have
> a reference to the object.

Everyone has a reference to built-ins so a bug or an attacker could free
built-ins.


> Thus, any code that would set my reference
> to undefined could only do so if it was also capable of mutating the
> object in any other way (adding/removing properties, etc.)
>
> So, we already have this:
>
> function () {
> // acquire a ref from some external code
> // no way of knowing what else is sharing this object
> var x = func()
> x.foo = 'bar'
> // other code...
> doAnotherThing()
> // not guaranteed!
> assert(x.foo === 'bar')
> }
>
With non-configurable properties and making objects non-extensible, you
have a way to prevent this, a way to protect your objects from "action at a
distance". Even proxies are required to respect some invariants for the
sake of application securability.
The free operator you're proposing cannot be protected against. Anyone can
release any object it has a reference to without the object creator (or the
other object reference holder) having their word to say to prevent it.
That's unbalanced.



> Whenever you have a reference to an object that is shared with some
> other code, there's the potential for action at a distance.  The
> proposal here is to make that action a bit more powerful.
>
> I don't agree that it's necessarily a problem in production.  We free
> objects in other languages all the time.
>
I agree with you, C and C++ are absurdly unsafe languages. No wonder double
free and use after-free bugs are so common! As the rumor goes,
use-after-free bugs lead to security issues sometimes [1]. Really not an
example to follow in my opinion.

What do you think about the revokable proxy solution? I agree it's less
sexy than a 4-letter keyword operator, but it's close enough to standard
and seems to solve your short-term issue as efficiently.
Tom's shim [2] simulates the direct proxy API on top of the current V8's
one. It includes revokable proxies I see. It can work today (as in Sat Oct
27th 2012) I think.

David

[1] http://www.mozilla.org/security/announce/2012/mfsa2012-85.html (just
pick the first result Google gave me against "use after free security").
[2] https://github.com/tvcutsem/harmony-reflect
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121027/83fb9ddb/attachment.html>


More information about the es-discuss mailing list