Defense against prototype pollution and supply chain attacks

At @agoric, we’ve begun investigating how compatible CosmJS is with SES such that projects using CosmJS can use tools like SES and LavaMoat to mitigate supply chain and prototype pollution attacks.

To evaluate whether a module and its transitive dependencies can be initialized under SES, I’ve locally run the following script in each of the CosmJS library packages. These are the packages that all have a single entry-module named ./build/index.js.

require("ses/lockdown");
lockdown();
console.log(require("./build/index.js"));

This provides some basic assurance that these libraries could be used in a project using SES. Likely incompatibilities usually arise when a library depends on a shim or polyfill, and these can usually be fixed by using the corresponding “ponyfill”, like colors/safe instead of colors. (Though I would note, CosmJS depends much more heavily on the equivalent ansi-colors module that does not perform any prototype attacks monkey-patching.)

• encoding
• math
• proto-signing
• utils
• tendermint-rpc
• stargate
• launchpad
• crypto
• cosmwasm

The following depend on a broken ponyfill, observable-symbol/ponyfill, which we haved worked with Ben Lesh to fix. This fix comes in a new major version, so an explicit upgrade should get the remaining libraries working. https://github.com/benlesh/symbol-observable/pull/48

• json-rpc
• socket
• stream

Of the two applications, faucet and cli, the faucet appears to work with the SES lockdown snippet at the head of its bin.

#!/usr/bin/env node
require("ses/lockdown");
lockdown();

• faucet
• cli

The CLI runs into this mysterious error, far far from any likely cause:

  cosmjs/node_modules/ast-types/lib/types.js:281
                      throw new Error("missing name");
                      ^

  [Error <Object <[Object: null prototype] {}>>: missing name
    at Object.from (cosmjs/node_modules/ast-types/lib/types.js:281:27)
    at cosmjs/node_modules/ast-types/lib/types.js:247:71
    at Array.map (<anonymous>)
    at or (cosmjs/node_modules/ast-types/lib/types.js:247:37)
    at default_1 (cosmjs/node_modules/ast-types/def/core.js:267:25)
    at use (cosmjs/node_modules/ast-types/fork.js:47:31)
    at Array.forEach (<anonymous>)
    at Object.default_1 [as default] (cosmjs/node_modules/ast-types/fork.js:14:10)
    at Object.<anonymous> (cosmjs/node_modules/ast-types/main.js:18:24)
    at Module._compile (internal/modules/cjs/loader.js:1201:30)]

This is a great place to start. From this position, we would ideally add SES lockdown to the testing aparatus for each of these packages, so every pull request against them would be verified to remain compatible.

To this end, there are a number of ways that Jasmine and Karma are themselves not yet ready to run under environmental lockdown, largely because they use the infamous colors package, which in addition to monkey-patching String.prototype upon initialization, provides a “themes” feature that enables users to indirectly punch String.prototype at runtime.

Karma should work with this proposed and accepted fix to use colors/safe instead. It would be nice if it used ansi-colors just to reduce duplication among your transitive dependencies, but harmless otherwise. https://github.com/karma-runner/karma/pull/3548

• proposed changes
• landed
• released (requires karma > 5.2.1)
• integrated in cosmjs

Jasmine itself is largely compatible, because the only primordial it modifies is globalThis, and SES lockdown leaves this as an exercise to the user.

Jasmine Test Reporter makes uses of colors themes. To overcome this obstacle, we would need either an alternate test reporter plugin or a major version bump and an architecture more closely aligned with dependency injection. I’ve proposed the changes. The author finds them amenable. Work would need to be planned. https://github.com/bcaudan/jasmine-spec-reporter/issues/528

• proposed design
• implemented design
• landed
• released
• integrated in cosmjs

The nature of SES compatibility exploration is that it is easier to keep than to obtain. There may be further obstacles behind these first exceptions I’ve encountered, but overall, it seems CosmJS is very nearly already compatible with SES and could encourage users to use it (and LavaMoat) to protect their applications from these kinds of attack.

[kriskowal]

Summary of what’s happened so far:

• The karma test runner released with a fix for SES compatibility https://github.com/karma-runner/karma/pull/3548
• The jasmine-spec-reporter released a major upgrade with SES compatibility https://github.com/bcaudan/jasmine-spec-reporter/pull/538
• symbol-observable@2.0.3 has been released. This version can run under SES with some small changes to how it’s used. CosmJS uses this through its dependency on xstream, which in turn uses most, which is only dependent upon it to the extent it’s necessary to pass its own tests. Once these dependencies use the new version, we’ll be able to upgrade them in CosmJS which will make CosmJS combine well with SES. xstream in particular needed TypeScript support for the symbol-observable change.
• I have an open change to most in review at https://github.com/cujojs/most/pull/541. This entailed an upgrade for symbol-observable, changes to how the library uses symbol-observable, and an additional dependency on globalthis to facilitate that.
• I have a draft change to xstream https://github.com/staltz/xstream/pull/315 This is pending a release of most with the above changes, and will require a similar treatment as the change to most.

The pending work, in steps, is:

1. Await a new release of most. I anticipate no further work.
2. Finish integrating most into xstream and await a new release.
3. Upgrade the new xstream in cosmjs packages and propose changes. At this point cosmjs is SES compatible.
4. Upgrade the karma and jasmine-spec-reporter dependencies of cosmjs and propose changes. At this point, cosmjs will have continuous verification of SES compatibility.

[kriskowal]

I’m delighted to share, jasmine-test-reporter@6 relieves the dependency on String.prototype pollution from colors. There is a minor API change, where the color theme must be expressly provided to the reporter.

• https://github.com/bcaudan/jasmine-spec-reporter/issues/528#issuecomment-695767209
• https://github.com/bcaudan/jasmine-spec-reporter/pull/538