You too can run malware from NPM (I mean without consequences)

Yeah, It’s merely a fluke that the malware author used some crappy online obfuscator that created those hex code variables. It would have been less work and less suspicious if they just kept their original semantic variables like “originalFetch”.

It is just about bringing the classic non-signature based antivirus software to the release cycle. Hard to say how useful it is, but usually it is endless cat-and-mouse play like with everything else.

It wouldn't be just one signal, but several - like a mere patch version that adds several kilobytes of code, long lines, etc. Or a release after a long silent period.

A complexity per line check would have flagged it.

Even a max line length check would have flagged it.

Feels like a basic light weight 3b AI model could easily spot shit like this on commit

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)

Not through e-mail links though, that's what caused this in the first place. E-mail notification, sure, but they should also do a phishing training mail - make it legit, but if people press the link they need to be told that NPM will never send them an email with a link.

With NPM now supporting OIDC, you can just turn this off now https://docs.npmjs.com/trusted-publishers

I think most people are fine with promoting a cool project you work on, but it's best practice to disclose that in the article. Even something like "If your project was set up with LavaMoat (a project I've been working on), ..." would be enough.

I think that's why they made the comment.

I'm often curious about how effective runtime quasi-sandboxing is in practice (at least until support at the TC39 level lands).

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.

> but provide some kind of 'verified' badge to the package

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

They already have this

https://docs.npmjs.com/trusted-publishers

https://docs.npmjs.com/generating-provenance-statements

I always thought this would be the ideal monetization path for NPM; enterprises pay them, NPM only supplies verified package releases, ideally delayed by hours/days after release so that anything that slips through the cracks has a chance to get caught.

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.

They do, I use a yubikey and it requires me to authenticate with it whenever I publish. They do support weaker 2fa methods as well, but you can choose.

Original author could be evil. 2fa does nothing.

According to the OP, in this specific case, the malware was mostly just intercepting legitimate fetch(), etc calls. With CSP `connect-src`, I don't think that would be possible unless the new fetch targets are themselves on allow-listed domains (which is a totally separate issue).

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.

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)

Huh. I read TFA in detail (and shared with my team), but I didn’t see any analysis. (?)

I'm actually shocked they have not stolen more seeing the breach impact radius? Perhaps we can thank wallets and exchanges for blacklisting the addresses and showing huge warnings like the one shown in the article.

Well there is jsr now....

Have you tried to find ways to break it?

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?