eval() in FF3 - just in case...

[Mario Heiderich]

http://peter.michaux.ca/article/8069

Just in case this is not known/intercepted yet.

Greetings,
.mario

[Mark S. Miller]

On Fri, Jun 27, 2008 at 1:44 AM, Mario Heiderich
<Mario.H...@googlemail.com> wrote:
>
> http://peter.michaux.ca/article/8069
>
> Just in case this is not known/intercepted yet.

Wow. No, we had no idea. I admit that I am shocked that the one tight
encapsulation mechanism in JavaScript itself -- lexical closures --
has now been ruined. Fortunately, all safe JavaScript subsets (Caja,
Cajita, ADsafe, FBJS, Jacaranda) already prevent access to the eval
function, as they must. So we should all be safe from this particular
new hole. However, so long as browser vendors feel free to quietly
introduce holes this large in existing functions...

--
Cheers,
--MarkM

[Brendan Eich]

On Jun 27, 2008, at 9:03 AM, Mark S. Miller wrote:

> On Fri, Jun 27, 2008 at 1:44 AM, Mario Heiderich
> <Mario.H...@googlemail.com> wrote:
>>
>> http://peter.michaux.ca/article/8069
>>
>> Just in case this is not known/intercepted yet.
>
> Wow. No, we had no idea. I admit that I am shocked that the one tight
> encapsulation mechanism in JavaScript itself -- lexical closures --
> has now been ruined.

There's no "now" -- this old eval extension was added over ten years
ago:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/js/src/
jsobj.c&rev=3.2&mark=580-590

3.2 <fur> 1998-04-23 17:30
Initial checkin of JavaScript 1.3, migrated from JSFUN13_BRANCH in /m/
src repository

This eval extension, if memory serves (I was in mozilla.org at the
time, not in the JS group at Netscape) originated in conversations
with Microsoft's rep during ECMA-262 standardization, trying to reach
agreement on a way to eval in other scopes.

> Fortunately, all safe JavaScript subsets (Caja,
> Cajita, ADsafe, FBJS, Jacaranda) already prevent access to the eval
> function, as they must. So we should all be safe from this particular
> new hole. However, so long as browser vendors feel free to quietly
> introduce holes this large in existing functions...

Mark, just because you discovered this does not mean that it was just
added. That you jumped to this conclusion makes me think "browser
vendors" (or really, Netscape then, but you must mean Mozilla now)
are fair game for collective blame. I hope not.

We've been removing old eval extensions (or pre-ECMA-262 modes, some
of this pre-dates standardization) in Firefox releases as we wean
people off of them. First to go was eval as a method on
Object.prototype -- that's gone in Firefox 3, and I mentioned this to
Doug at the January Ecma TC39 face to face (he did not know and had
thought that we couldn't remove it). We will remove this optional
second argument in a future release, as soon as we can.

I'd like to point out, while we are on this subject, that various
"secure eval" discussions and proposals in Ecma TC39/TG1 going back
to 2006, including

http://wiki.ecmascript.org/doku.php?
id=meetings:minutes_jul_27_2006#multiple_compilation_units
http://wiki.ecmascript.org/doku.php?id=es3.1:secure_eval

have run the risk (depending on how they are specified in detail) of
opening this hole in the standardized language. See

http://wiki.ecmascript.org/doku.php?id=discussion:resurrected_eval

where the hazard of any kind of scope or context second argument to
eval is raised by Lars Hansen.

This hazard is exactly what Peter rediscovered. From the Ajaxian
thread it seems people are trying to devise workarounds that wrap
eval and try to tame it. The only safe course is to wrap eval and
suppress the second argument entirely.

This bug tracks removal of eval's optional second argument:

https://bugzilla.mozilla.org/show_bug.cgi?id=442333

/be

[Mark S. Miller]

On Fri, Jun 27, 2008 at 12:39 PM, Brendan Eich <bre...@mozilla.org> wrote:
> There's no "now" -- this old eval extension was added over ten years ago:
>
> http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/js/src/jsobj.c&rev=3.2&mark=580-590

Hi Brendan, I was completely unaware of this history and did indeed
think that this was a newly opened hole. I'm very pleased to find that
it isn't. I'm especially pleased to hear that you folks plan to remove
this in a future release. Thanks for the clarification!

--
Cheers,
--MarkM

[Douglas Crockford]

On Jun 27, 12:39 pm, Brendan Eich <bren...@mozilla.org> wrote:

> This eval extension, if memory serves (I was in mozilla.org at the  
> time, not in the JS group at Netscape) originated in conversations  
> with Microsoft's rep during ECMA-262 standardization, trying to reach  
> agreement on a way to eval in other scopes.

So it was Microsoft's fault. You should never listen to those guys.

The secure eval proposal would not have opened this hole. It would be
completely safe when the context included only number, string, and
boolean values. But if the context contained an object, then the
attacker could get to Object and do bad things to Object.prototype.
There are use cases that would benefit even with the restriction to
simple values, but it was limited enough to be judged a low value
feature and we dropped it.

It contained nothing like the problem that Peter discovered.

ES3.1 can now freeze the central objects, so safe eval could be made
truly safe.

[Gareth]

Strange how the function only shows 1 argument:-
javascript:alert(eval.length)//1