One of the guarantees that strict mode provides is that in strict function code, the identifier arguments always refers to that function’s Arguments object.
function fn () {
'use strict';
// malicious code
arguments // still refers to the function's Arguments object
}
So, no matter what code is injected at // malicious code, the arguments identifier is immutably bound to the function’s Arguments object during the entire function invocation.
I was wondering if the same guarantees are provided for the eval identifier, i.e. does the eval identifier with guarantee refer to the built-in global eval function at all times?
I’d like to point out that the above mentioned guarantee is not provided if our strict code is nested within non-strict code. Non-strict code is allowed to create local "eval" bindings, or to mutate the global "eval" binding. (Also, if another non-strict program uses the same global object (as in a web-page containing multiple scripts), the above mentioned guarantee is also not provided.)
So, for the sake of this question, I’d like to define the following scenario:
- our program is stand-alone, i.e. it doesn’t share its global object with any other program,
-
our program consists of a single strict IIFE, like so:
(function () { 'use strict'; // malicious code eval // does it still refer to the built-in global eval function? }());
Given these conditions, is it possible to inject code at \\ malicious code, that will change the value of the eval identifier?
Theoretically it should not be possible to reassign the
evalidentifier to something other than theevalproperty of the global object, or mask it with a local variable, according to annex C:…
…
…and so on.
As discussed below, it’s possible to change the global eval function by assigning a new value to that property of the global object. A reference to the global object can be obtained by an indirect call to
evalin strict mode:You could extend that to something that will work reliably in non-strict mode as well:
…and then assign its
evalproperty to something else.While
evalwill still be identical to theevalproperty of the global object, it won’t be the built-inevalanymore, which should meet your conditions.