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

'No way to prevent this,' says only package manager where this regularly happens

kevinpatel.xyz

Post reply on HN
Print view View original

81–90 of 230 posts

Re: 'No way to prevent this,' says only package manager where this regularly happens

#81

Post by 827a »

Rohansi wrote: post #38
827a wrote: post #30

There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will only run postinstall scripts for versions of packages published before ${today}".

This doesn't really fix the issue though because package code is also executed at build time and during testing. Just maybe restricts the scope a little bit.

There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package). Different attack profile. Worse in some ways (your CI likely has NPM push tokens, which is how this single-package worm become a multi-package self-replicating worm) (your CI pipeline also likely has some level of privileged access to your cloud environment; deployed services are more likely to be highly scoped). But, better in some ways.

Its childish to believe that because you can't fix everything you shouldn't fix anything. Defense in depth.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#82

Post by com2kid »

brunoborges wrote: post #80
cluckindan wrote: post #59

Earlier quoted context omitted.

How does that protect against credential theft? MFA required to sign published releases?

That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype. But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they a…

> Enforce scope (namespace) requirement, and require external verification (reverse DNS for example).

Who the heck says everyone who publishes a library has a domain? That seems absurd.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#84

Post by drdaeman »

est31 wrote: post #41
nothinkjustai wrote: post #29

Earlier quoted context omitted.

Rust doesn’t have post install scripts

There is build.rs, proc macros are unsandboxed, and lastly you install the binary so that you can run it. Even if the build and install were fully sandboxed, the binary could still do malicious stuff if ran.

Even without post-install script, a malicious payload could be hiding in some function and just wait until the developer invokes `cargo run`. Not that many people audit the crates they pull into their projects.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#85

Post by bichiliad »

jollyllama wrote: post #20
aselimov3 wrote: post #8

What are the actual guarantees that go/Rust make that Python/npm don’t? It seems like it might just be that Python/npm are juicier targets? I’m starting to try and avoid all third party packages

> It seems like it might just be that Python/npm are juicier targets? Attackers go where the victims are. Frontend is a monoculture with the vast majority using NPM; backend, less so. This isn't an excuse for NPM, but another strike against it. You could also argue that the attacks make a deeper point about frontend vs backend devs, but I won't go there.

Why would you even imply something like that?

Re: 'No way to prevent this,' says only package manager where this regularly happens

#86

Post by radlad »

com2kid wrote: post #82
brunoborges wrote: post #80

Earlier quoted context omitted.

That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype. But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they a…

> Enforce scope (namespace) requirement, and require external verification (reverse DNS for example). Who the heck says everyone who publishes a library has a domain? That seems absurd.

And domains can change hands legitimately.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#87

Post by anonzzzies »

spaqin wrote: post #77

It's a cultural issue, always feeling the urge to update to the newest possible package for things that are already working fine, without even reading the changelog to see if it's applicable. Cooldowns are only a way to force a bit of patience onto the maintainers... and they work.

That, and package owners updating stuff that needs no updating just to look not stale/unupdated. I can use lisp packages without changes for 15 years fine, but a js one is unmaintained! oh no! Even though it was done 15 years ago, so they add nothing, sometimes a breaking change, to up a version on npm and github and look maintained. And then everything will update.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#88

Post by 827a »

raggi wrote: post #39
827a wrote: post #30

There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will only run postinstall scripts for versions of packages published before ${today}".

install scripts are a distraction, just like package signatures are a distraction. adding/removing either feature has no significant impact on the wormability of this package ecosystem. installed npm code is run, with nearly zero exceptions.

> There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package). Different attack profile. Worse in some ways (your CI likely has NPM push tokens, which is how this single-package worm become a multi-package self-replicating worm) (your CI pipeline also likely has some level of privileged access to your cloud environment; deployed services are more likely to be highly scoped). But, better in some ways.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#89

Post by brunoborges »

com2kid wrote: post #82
brunoborges wrote: post #80

Earlier quoted context omitted.

That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype. But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they a…

> Enforce scope (namespace) requirement, and require external verification (reverse DNS for example). Who the heck says everyone who publishes a library has a domain? That seems absurd.

Sonatype allows "io.github." as a valid groupId and has a process to verify ownership. I am sure other providers like GitLab can work on this.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#90

Post by apf6 »

akoboldfrying wrote: post #72
827a wrote: post #30

There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will only run postinstall scripts for versions of packages published before ${today}".

With respect, post-install scripts are a total red herring. You're alarmed by them because they are code controlled by someone else that runs on your box, and they could do something bad -- yes, they are, and yes they could. But so is the regular code in those packages! It won't run at install time, but something in there will run -- otherwise it wouldn't have been included in the dependencies. Thinking that eliminat…

The time difference does matter though. There were some recent worm attacks in NPM that spread very quickly because they used post-install. I don’t remember how long it took NPM to block the packages but it was probably around 30 minutes or so? If it wasn’t for post-install then that same attack would have a much slower spread and thus a smaller blast radius.
Post reply on HN