Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

81–90 of 122 posts

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

#81

Post by naugtur »

cluckindan wrote: post #75
naugtur wrote: post #16

Earlier quoted context omitted.

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)

Well, that’s not exactly reassuring. Having a very different runtime environment in production is grounds for hard to debug issues. 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.

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.

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

#82

Post by riazrizvi »

Glad to see this article raising awareness.

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.

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

#84

Post by erpderp »

In the example snippets from OP, the code shown is in the browser. I'm failing to see how the interception, as described, couldn't be handled by a decent Content Security Policy - instead of requiring yet another npm package. Seems safer than installing another package to address risk from ... installing packages.

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

#85

Post by chatmasta »

cluckindan wrote: post #76
mystifyingpoi wrote: post #45

Earlier quoted context omitted.

Detecting sketchy-looking hex codes should be pretty straightforward, but then I imagine there are ways to make sketchy code non-sketchy, which would be immediately used. I can imagine a big JS function, that pretends to do legit data manip, but in the process creates the payload.

A complexity per line check would have flagged it. Even a max line length check would have flagged it.

That would flag a huge percentage of JS packages that ship with minified code.

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

#86

Post by ghrl »

erpderp wrote: post #84

In the example snippets from OP, the code shown is in the browser. I'm failing to see how the interception, as described, couldn't be handled by a decent Content Security Policy - instead of requiring yet another npm package. Seems safer than installing another package to address risk from ... installing packages.

I suppose if you're using a bundler, you will ship JS bundles including the malicious packages from your own trusted domain. How could CSP prevent this or similar attacks?

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

#87

Post by madeofpalk »

AtNightWeCode wrote: post #73
jefozabuss wrote: post #34

Seems like people already forgot about Jia Tan. 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...

The problem is that it is even possible to push builds from dev machines.

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

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

#88

Post by madeofpalk »

sesm wrote: post #5
mohsen1 wrote: post #3

npm should take responsibility and up their game here. It’s possible to analyze the code and mark it as suspicious and delay the publish for stuff like this. It should prevent publishing code like this even if I have a gun to my head

I think malware check should be opt-in for package authors, but provide some kind of 'verified' badge to the package. Edit: typo

They already have this

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

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

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

#90

Post by erpderp »

ghrl wrote: post #86
erpderp wrote: post #84

In the example snippets from OP, the code shown is in the browser. I'm failing to see how the interception, as described, couldn't be handled by a decent Content Security Policy - instead of requiring yet another npm package. Seems safer than installing another package to address risk from ... installing packages.

I suppose if you're using a bundler, you will ship JS bundles including the malicious packages from your own trusted domain. How could CSP prevent this or similar attacks?

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.

Post reply on HN