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

Pnpm has a new setting to stave off supply chain attacks

pnpm.io

Post reply on HN
Print view View original

101–110 of 152 posts

Re: Pnpm has a new setting to stave off supply chain attacks

#101

Post by hobofan »

DougBTX wrote: post #61
mcintyre1994 wrote: post #29

Earlier quoted context omitted.

In the case of the chalk/debug etc hack, the first detection seemed to come from a CI build failure it caused: https://jdstaerk.substack.com/p/we-just-found-malicious-code... > It started with a cryptic build failure in our CI/CD pipeline, which my colleague noticed > This seemingly minor error was the first sign of a sophisticated supply chain attack. We traced the failure to a small dependency, error-ex. Our packag…

> Our package-lock.json specified the stable version 1.3.2 or newer Is that possible? I thought the lock files restricted to a specific version with an integrity check hash. Is it possible that it would install a newer version which doesn't match the hash in the lock file? Do they just mean package.json here?

Since nobody else answers your question:

> Do they just mean package.json here?

Yes, most likely. A package-lock.json always specifies an exact version with hash and not a "version X or newer".

Re: Pnpm has a new setting to stave off supply chain attacks

#102

Post by __MatrixMan__ »

mort96 wrote: post #80
__MatrixMan__ wrote: post #54

Earlier quoted context omitted.

The problem is that they implicitly do so. If they had to enter the hash of the latest and greatest version, the onus would be on them at that time to scrutinize it. At worst the spread of the malicious package would be slowed, and at best it would be stopped.

Surely you'd achieve the same thing by making people manually enter a new version number? I'm not inherently against the idea of specifying a hash, it would protect against NPM hosting infrastructure being compromised, but again, that's not what we're seeing here

If you end up with bits that hash to 0xabc123 and I end up with bits that hash to 0x456def and we both think we installed fooapp version 7.8.9, there's nothing about the version number that tells us which one of us has been hacked.

But if we both attempt to install 0x456def, it's clear that whoever has 0xabc123 is in trouble. This is especially important in cases where you might need a package while you're on a separate network partition than npm. Any peer can provide it and you know it hasn't been tampered with because if it had been it would have a different hash.

Re: Pnpm has a new setting to stave off supply chain attacks

#104

Post by otterley »

ozim wrote: post #16
OskarS wrote: post #6

I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking,…

NPM packages follow semantic versioning so minor versions should be fine to auto update. (there is still an issue what for package maintainer might be minor not being minor for you - but let's stick to ideal world for that) I don't think people are having major versions updated every month, it is more really like 6 months or once a year. I guess the problem might be people think auto updating minor versions in CI/CD…

> so minor versions should be fine to auto update

The problem is that "should" assumes that point releases never introduce regressions (whether they be security, performance, or correctness). Unfortunately, history has shown that regressions can and do happen. The best practice for release engineering (CI/CD, if you will) is to assume the worst, test thoroughly, and release incrementally (include bake time).

Delaying updates isn't just a backstop against security vulnerabilities; it's useful for letting the dust settle after an update of any kind that can adversely impact the application. The theory is that someone will find it before you, report it, and that a fix will be issued.

Re: Pnpm has a new setting to stave off supply chain attacks

#105

Post by kjok »

hobofan wrote: post #100
kjok wrote: post #93

Earlier quoted context omitted.

> automated scanners seem to do a good job already of finding malicious packages. That's not true. This latest incident was detected by an individual researcher, just like many similar attacks in the past. Time and again, it's been people who flagged these issues, later reported to security startups, not automated tools. Don't fall for the PR spin. If automated scanning were truly effective, we'd see deployments acro…

> If automated scanning were truly effective, we'd see deployments across all major package registries. No we wouldn't. Most package registries are run by either bigcorps at a loss or by community maintainers (with bigcorps again sponsoring the infrastructure). And many of them barely go beyond the "CRUD" of package publishing due to lack of resources. The economic incentives of building up supply chain security tool…

You're right that registries are under-resourced. But, if automated malware scanning actually worked, we'd already see big tech partnering with package registries to run continuous, ecosystem-wide scanning and detection pipelines. However, that isn't happening. Instead, we see piecemeal efforts from Google with assurance artifacts (SLSA provenance, SBOMs, verifiable builds), Microsoft sponsoring OSS maintainers, Facebook donating to package registries. Google's initiatives stop short of claiming they can automatically detect malware.

This distinction matters. Malware detection is, in the general case, an undecidable problem (think halting problem and Rice theorem). No amount of static or dynamic scanning can guarantee catching malicious logic in arbitrary code. At best, scanners detect known signatures, patterns, or anomalies. They can't prove absence of malicious behavior.

So the reality is: if Google's assurance artifacts stop short of claiming automated malware detection is feasible, it's a stretch for anyone else to suggest registries could achieve it "if they just had more resources." The problem space itself is the blocker, not just lack of infra or resources.

Re: Pnpm has a new setting to stave off supply chain attacks

#106

Post by acdha »

kjok wrote: post #91
acdha wrote: post #51

Earlier quoted context omitted.

Think about how the three major recent incidents were caught: not by individual users installing packages but by security companies running automated scans on new uploads flagging things for audits. This would work quite well in that model, and it’s cheap in many cases where there isn’t a burning need to install something which just came out.

I think there's some confusion here. No automated scan was able to catch the attack. It was an individual who notified these startups.

Quite possibly - there have been several incidents recently and a number of researchers working together so it’s not clear exactly who found something first and it’s definitely not as simple to fix as tossing a tool in place.

The CEO of socket.dev described an automated pipeline flagging new uploads for analysts, for example, which is good but not instantaneous:

https://news.ycombinator.com/item?id=45257681

The Aikido team also appear to be suggesting they investigated a suspicious flag (apologies if I’m misreading their post), which again needs time for analysts to work:

https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...

My thought was simply that these were caught relatively quickly by security researchers rather than by compromised users reporting breaches. If you didn’t install updates with a relatively short period of time after they were published, the subsequent response would keep you safe. Obviously that’s not perfect and a sophisticated, patient attack like liblzma suffered would likely still be possible but there really does seem to be a value to having something like Debian’s unstable/stable divide where researchers and thrill-seekers would get everything ASAP but most people would give it some time to be tested. What I’d really like to see is a community model for funding that and especially supporting independent researchers.

Re: Pnpm has a new setting to stave off supply chain attacks

#107

Post by chuckadams »

__MatrixMan__ wrote: post #74
debazel wrote: post #72

Earlier quoted context omitted.

> If I can get you to use malicious code in the first place I can also trick you into upgrading from safe code to the vulnerable code in the name of "security". Isn't the whole point that malicious actors usually only have a very short window where they can actually get you to install anything, before shut out again? That's the whole point of having a delay in the package-manager.

Who is going to discover it in that time? Not the maintainers, they've already released it. Their window for scrutiny has passed. There is some sense in giving the early adopters some time to raise the alarm and opting into late adoption, but isn't that better handled by defensive use of semantic versioning? Consider the xzutils backdoor. It was introduced a month before it was discovered, and it was discovered by a…

The xz backdoor went undetected so long partly because the build scripts were already so hairy and baroque that no one noticed the extra obfuscations that ran code out of a binary blob in test data. None of which was even in the source repo, it was dropped into the package build scripts externally just before pushing them to the apt/rpm package repositories.

Re: Pnpm has a new setting to stave off supply chain attacks

#108

Post by streptomycin »

Rockslide wrote: post #71
streptomycin wrote: post #64

Earlier quoted context omitted.

If they were for some reason doing `npm install` rather than `npm ci`, then `npm install` does update packages in the lock file. Personally I always found that confusing, and yarn/pnpm don't behave that way. I think most people do `npm ci` in CI, unless they are using CI to specifically test if `npm install` still works, which I guess maybe would be a good idea if you use npm since it doesn't like obeying the lock fi…

How does this get repeated over and over, when it's simply not true? At least not anymore. npm install will only update the lockfile if you make changes to your package.json. Otherwise, it will install the versions from the lockfile.

My bad, it really annoyed me when npm stopped respecting lockfiles years ago so I stopped using it. That's great news that they eventually changed their mind.

However in rare cases where I am forced to use it to contribute to some npm-using project, I have noticed that the lockfile often gets updated and I get a huge diff even though I didn't edit the dependencies. So I've always assumed that was the same issue with npm ignoring the lockfile, but maybe it's some other issue? idk

Re: Pnpm has a new setting to stave off supply chain attacks

#109

Post by kardianos »

It seems like the core problem is (1) NPM node_modules is so large usually, no one actually audit them and (2) the NPM churn is so great, no one audits them and (3) the design of NPM appears to think that automatically updating point or minor versions is actually good and desirable.

Go is one of the few packing systems that got these right.

Re: Pnpm has a new setting to stave off supply chain attacks

#110

Post by nikanj »

acdha wrote: post #51
postepowanieadm wrote: post #2

If everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to detect an incident.

Think about how the three major recent incidents were caught: not by individual users installing packages but by security companies running automated scans on new uploads flagging things for audits. This would work quite well in that model, and it’s cheap in many cases where there isn’t a burning need to install something which just came out.

Automated scans have detected 72251 out of the previous 3 supply-chain attacks
Post reply on HN