Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Defense against prototype pollution and supply chain attacks

See original GitHub issue

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.


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.

  • 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
  • faucet
  • cli

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

                      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 (<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.

  • 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.

  • 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.

Issue Analytics

  • State:open
  • Created 3 years ago
  • Reactions:5
  • Comments:15 (6 by maintainers)

github_iconTop GitHub Comments

kriskowalcommented, Mar 25, 2021

Summary of what’s happened so far:

  • The karma test runner released with a fix for SES compatibility
  • The jasmine-spec-reporter released a major upgrade with SES compatibility
  • 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 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 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.
kriskowalcommented, Sep 20, 2020

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

What Is Prototype Pollution? | Risks & Mitigation - Imperva
In a prototype pollution attack, threat actors inject properties into existing JavaScript construct prototypes ... This is referred to as a prototype chain....
Read more >
Prototype pollution: The dangerous and underrated ...
The security hole was a prototype pollution bug – a type of vulnerability that allows attackers to exploit the rules of the JavaScript ......
Read more >
Everything you need to know about Prototype Pollution
Prototype Pollution is a vulnerability that allows attackers to exploit the rules of the JavaScript programming language, by injecting properties into ...
Read more >
What is prototype pollution? | Tutorial & examples - Snyk Learn
Prototype pollution is an injection attack that targets JavaScript runtimes. With prototype pollution, an attacker might control the default values of an ...
Read more >
The Complete Guide to Prototype Pollution Vulnerabilities
Prototype Pollution is one of the less known vulnerabilities in the security community. Researchers started to discuss it as a potential ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found