eval vs lookup
John J Barton
I can get an object this way:
var obj = window["foo"];
or
var obj = eval("window.foo");
If I am in an extension then I'll end up with something like:
var obj = win.wrappedJSObject["foo'];
or
var obj = eval(win.wrappedJSObect.foo);
Now suppose foo is a getter function in the page. Is the eval secure?
Is the lookup secure?
jjb
Philip Chee
How about testing for a getter first?
var g = window.__lookupGetter__("foo");
if (g) {
....decompile your getter....
}
else
{
....
}
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Boris Zbarsky
You mean someone did window.__defineGetter__("foo", somefunction)?
Secure in what sense? Not being exploitable? If so, the lookup is
secure as long as you're working with win.wrappedJSObject or some other
XPCSafeJSObjectWrapper. I _think_ the eval should be, but I'm not sure.
-Boris
John J Barton
> On 11/6/09 6:49 PM, John J Barton wrote:
>> If I have window.foo = {some:"thing"};
>> I can get an object this way:
>> var obj = window["foo"];
>> or
>> var obj = eval("window.foo");
>>
>> If I am in an extension then I'll end up with something like:
>> var obj = win.wrappedJSObject["foo'];
>> or
>> var obj = eval(win.wrappedJSObect.foo);
>>
>> Now suppose foo is a getter function in the page. Is the eval secure? Is
>> the lookup secure?
>
> You mean someone did window.__defineGetter__("foo", somefunction)?
yes
>
> Secure in what sense? Not being exploitable?
As in "the web page cannot again privileges".
> If so, the lookup is
> secure as long as you're working with win.wrappedJSObject or some other
> XPCSafeJSObjectWrapper.
So I guess 'win' is a view of the nsIDOMWindow without any changes the
page may have applied, while "win.wrappedJSObject" is the same with the
changes, and both are in XPCSafeJSObjectWrapper?
> I _think_ the eval should be, but I'm not sure.
I guess eval() is safe if the operations in the string are safe, and
vice versa.
jjb
Boris Zbarsky
>> Secure in what sense? Not being exploitable?
>
> As in "the web page cannot again privileges".
Right; same thing. ;)
> > If so, the lookup is
>> secure as long as you're working with win.wrappedJSObject or some
>> other XPCSafeJSObjectWrapper.
>
> So I guess 'win' is a view of the nsIDOMWindow without any changes the
> page may have applied
Yes.
> while "win.wrappedJSObject" is the same with the
> changes, and both are in XPCSafeJSObjectWrapper?
win.wrappedJSObject is an XPCSafeJSObjectWrapper. All
XPCSafeJSObjectWrapper does is expose web-page added JS stuff in a way
that's safe to access in the "web page cannot gain privileges" sense.
If you don't .wrappedJSObject here you can't see the web-page-added
stuff at all, which is safe.
> I guess eval() is safe if the operations in the string are safe, and
> vice versa.
One would hope, but I can't guarantee that. I just don't know what
codepath eval follows....
-Boris
Blake Kaplan
> If I have window.foo = {some:"thing"};
> I can get an object this way:
> var obj = window["foo"];
> or
> var obj = eval("window.foo");
In general, these two are almost exactly the same. However, you *really* want
to prefer the former to the latter. In particular, using eval:
- Inhibits optimizations (such as the JIT).
- Is a red flag for anybody doing a security review (and anybody looking at
the code has to spend a bunch more time understanding what's going on).
- Requires us to spin up the parser and compile more code, which is slow.
> If I am in an extension then I'll end up with something like:
> var obj = win.wrappedJSObject["foo'];
> or
> var obj = eval(win.wrappedJSObect.foo);
Missing quotes here, right? As written, the latter statement is a security
problem.
> Now suppose foo is a getter function in the page. Is the eval secure?
> Is the lookup secure?
It is secure in that the act of getting the property won't result in privilege
escalation.
--
Blake Kaplan
John J Barton
> John J Barton <johnj...@johnjbarton.com> wrote:
>> If I have window.foo = {some:"thing"};
>> I can get an object this way:
>> var obj = window["foo"];
>> or
>> var obj = eval("window.foo");
>
> In general, these two are almost exactly the same. However, you *really* want
> to prefer the former to the latter. In particular, using eval:
> - Inhibits optimizations (such as the JIT).
> - Is a red flag for anybody doing a security review (and anybody looking at
> the code has to spend a bunch more time understanding what's going on).
This is why I asked, but I don't understand the answer. It sounds like
the red flag is bogus: the eval() is not a security issue after all. But
below is the opposite?
> - Requires us to spin up the parser and compile more code, which is slow.
>
>> If I am in an extension then I'll end up with something like:
>> var obj = win.wrappedJSObject["foo'];
>> or
>> var obj = eval(win.wrappedJSObect.foo);
>
> Missing quotes here, right? As written, the latter statement is a security
> problem.
? So some expressions in eval() are insecure while the same expression
in a script tag are secure?
>
>> Now suppose foo is a getter function in the page. Is the eval secure?
>> Is the lookup secure?
>
> It is secure in that the act of getting the property won't result in privilege
> escalation.
Ok, but what makes it security problem then?
jjb
Boris Zbarsky
>>> If I am in an extension then I'll end up with something like:
>>> var obj = win.wrappedJSObject["foo'];
>>> or
>>> var obj = eval(win.wrappedJSObect.foo);
>>
>> Missing quotes here, right? As written, the latter statement is a
>> security
>> problem.
>
> ? So some expressions in eval() are insecure while the same expression
> in a script tag are secure?
The key was "missing quotes here". Your eval expression will get the
value of win.wrappedJSObject.foo and then eval it as a string. That
string is under control of content, so that eval statement allows
arbitrary code execution by content. Had you written:
var obj = eval("win.wrappedJSObject.foo");
it would be equivalent to the non-eval version (and secure, per blake's
comments).
Or in other words, the expressions are NOT the same.
The lesson being, don't use eval. Period. Far too easy to shoot
yourself in the foot.
> Ok, but what makes it security problem then?
See above.
-Boris
Boris Zbarsky
> The lesson being, don't use eval. Period. Far too easy to shoot yourself
> in the foot.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=528950 on spiking
this particular gun.
-Boris