Direct link to Code:
https://www.lunasec.io/docs/blog/node-ipc-protestware#a-look...
Edit: I tried to link directly there but it didn't work. The "hash fragment" in my submitted URL doesn't actually make it's way through the Hacker News link filter. My apologies to everybody for having to scroll to the bottom to actually get to the "real code"! Here is the link to use instead up above. (The rest is my OG comment)
------
My colleague and I wanted to understand how this malware/Protestware worked, so we took the time to manually de-obfuscate the code that was bundled with the recent "node-ipc" NPM package to find out.
It's pretty simple and makes it clear that this wasn't very "advanced" malware. It was very much an emotionally motivated Open Source dev wanting to use their "power" to protest the war. The impact of a more sophisticated attack is... something I think about a lot about how to fix.
That's why this is another good reminder to keep thinking about how we can actually "fix" these types of supply-chain attacks. Here is a list of malware in a spreadsheet[0] from other authors that also have protestware bundled. (It's in Russian but the Google Translate browser extension worked for me.)
I wrote a blurb at the bottom of this blog post when we published it talking about mitigating "bad" NPM packages, and I need to update it to add a bit about projects like Deno[1] that are attempting to solve this by "forking" the Node ecosystem.
Deno adds permissions per dependency (like a browser extension or phone app) and sandboxes all untrusted code by default. It's going to take us many years before we're at the point where a project like that is "production ready" but it's something that I'd encourage you to check out!
0: https://docs.google.com/spreadsheets/d/1H3xPB4PgWeFcHjZ7NOPt...
> Deno adds permissions per dependency
Another project heading in that direction is also an anagram of Node:
"The foundation of Endo is SES, a tamper-proof JavaScript environment that allows safe execution of arbitrary programs in Compartments. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies.
------
Nice! Thanks for sharing that link. I've done a bit of digging into that project before and it's definitely a very promising idea.
It has a lot of the same pitfalls as Dyno, imo, in that it would require somebody to define a "security policy" for every module to whitelist permissions.
But, it's also something that could maybe be attached similarly to how TypeScript types are "retroactively" added for existing vanilla JS NPM packages. Ie, packages that have never added their own type declarations (like `express`) can have their types added to DefinitelyTyped[0] and published as a separate NPM package (`@types/express`).
It works fairly well and something like `@endo-policies/express` wouldn't be crazy to add in later. Obviously it's going to be super painful, but fixing tech debt is always going to hurt.
vm2[1] is another Node project with some semi-similar goals that's worth mentioning. It's not designed to be "applied" in the same way as Endo, but it does give you a way to "sandbox" dependencies.
As a security person, I am weary to trust something like vm2 because it is much harder to "get right" than a "sandboxed-by-default" approach like Endo or Dyno. Look at this[2] CVE on vm2 from a few months ago for some evidence about _why_ this approach isn't ideal.
I'm optimistic for the future but we still have a long way to go before we get to it!
0: https://github.com/DefinitelyTyped/DefinitelyTyped
1: https://www.npmjs.com/package/vm2