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

Malicious npm packages detected across Red Hat Cloud Services

github.com

Post reply on HN
Print view View original

361–370 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#361

Post by joshspankit »

Devs and other people who have seen behind the scenes at large companies know that most security is at best shaky and mostly hand-waved

It’s not even really the fault of the people who pushed for these setups, it’s a seemingly simple business decision: build it in a way that looks secure, add some black-box process, and tell the overseers that the reason there are no attacks is because it’s bulletproof, and definitely not because no one has really tried

Then, when someone finally turns their attention to you and walks in: fire whoever needs to be fired, patch that specific hole, maybe spend a bunch of money on a different system, assure the overseers that it’s handled, and move on with business as usual

It’s cheaper in the long-run, it makes stockholders happy, it relieves the bosses and their bosses, and for the most part there are “no security holes”.

Until now, of course

Re: Malicious npm packages detected across Red Hat Cloud Services

#362

Post by simpaticoder »

ajross wrote: post #357
mnahkies wrote: post #352

In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintai…

IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate…

> The solution in the Linux world ... is that there is a second level of human beings...

AKA "unpaid labor". I don't think that's a good solution, either. Certainly it's only by pure luck that no malefactors have infiltrated the ad hoc, anonymous social proof communities that Linux depends on, and I don't think other systems should emulate it.

The real solution (for Linux too) is a paid package curation service. Or really, a small handful of them competing on price, speed, reliability.

Re: Malicious npm packages detected across Red Hat Cloud Services

#363

Post by Uvix »

Pxtl wrote: post #360
Uvix wrote: post #337

Earlier quoted context omitted.

NuGet is lock-by-default for the parent package, but with the move from packages.config to it's no longer lock-by-default for dependencies.

It never made sense the other way. If I reference a package, logically I'm also referencing its dependencies at the version that the package uses. Forcing the user to also reference dependencies of dependencies of dependencies means the package reference lists aren't DRY.

But just the dependency list isn't sufficient to pick a specific version, thanks to dependency ranges. If Package A depends on Package B >= 1.0, and Package B has v1.0 and v1.1 available, it will use v1.0. But if Package B suddenly unlists v1.0, then future restores will change to v1.1.

Re: Malicious npm packages detected across Red Hat Cloud Services

#364

Post by randusername »

mnahkies wrote: post #352

In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintai…

My read is that there's a crowd that is unimpressed with mechanistic changes when in their view there is a cultural issue.

From the outside looking in, web dev has this frantic wild west energy to it. Mutability, dynamic typing, standards changing constantly, frameworks changing constantly, continuous delivery, CDNs, live A/B campaigns, large numbers of dependencies, sensitive user data spread out across a lot of infrastructure.

I'm not saying that's an accurate view and I don't think "I told you so" is the right attitude, but I can understand the place it comes from.

Re: Malicious npm packages detected across Red Hat Cloud Services

#365

Post by nightpool »

simpaticoder wrote: post #362
ajross wrote: post #357

Earlier quoted context omitted.

IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate…

> The solution in the Linux world ... is that there is a second level of human beings... AKA "unpaid labor". I don't think that's a good solution, either. Certainly it's only by pure luck that no malefactors have infiltrated the ad hoc, anonymous social proof communities that Linux depends on, and I don't think other systems should emulate it. The real solution (for Linux too) is a paid package curation service. Or r…

There is a version of that. It is called RedHat Enterprise Linux. : )

Re: Malicious npm packages detected across Red Hat Cloud Services

#366

Post by ajross »

simpaticoder wrote: post #362
ajross wrote: post #357

Earlier quoted context omitted.

IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate…

> The solution in the Linux world ... is that there is a second level of human beings... AKA "unpaid labor". I don't think that's a good solution, either. Certainly it's only by pure luck that no malefactors have infiltrated the ad hoc, anonymous social proof communities that Linux depends on, and I don't think other systems should emulate it. The real solution (for Linux too) is a paid package curation service. Or r…

> Certainly it's only by pure luck that no malefactors have infiltrated the [pinko commie Linux hippy commune]

Yeah... no. Sorry, that's a wild misunderstanding of the economics of the Linux ecosystem, modern libertarian thought and the employment status of people with write access to the packaging layers.

Re: Malicious npm packages detected across Red Hat Cloud Services

#367

Post by jruohonen »

simpaticoder wrote: post #362
ajross wrote: post #357

Earlier quoted context omitted.

IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate…

> The solution in the Linux world ... is that there is a second level of human beings... AKA "unpaid labor". I don't think that's a good solution, either. Certainly it's only by pure luck that no malefactors have infiltrated the ad hoc, anonymous social proof communities that Linux depends on, and I don't think other systems should emulate it. The real solution (for Linux too) is a paid package curation service. Or r…

> ... a second level of human beings responsible for reviewing, auditing, packaging, and customizing those hacker-generated upstreams for the benefit of their users.

> The real solution (for Linux too) is a paid package curation service. Or really, a small handful of them competing on price, speed, reliability.

That was also what I was thinking aloud a moment ago. And there would be a business opportunity, too. Perhaps not like RHEL et al. full-blown stuff per se, but say smaller scale guarantees with different pricing; web, AI, scientific computing, and whatnot. At the pace things are progressing, I'd guess you might even get desktop etc. users on board (for nominal pricing).

Re: Malicious npm packages detected across Red Hat Cloud Services

#368

Post by gbear605 »

matheusmoreira wrote: post #99
gbear605 wrote: post #66

Earlier quoted context omitted.

One easy change would be that before any package can be published, it has to wait a minimum of two weeks in a state where it can be reviewed but it can't be installed without jumping through several hoops with big warning signs, things like "INSTALL_INTENTIONALLY_DANGEROUS_PACKAGES_THAT_WILL_BREAK_MY_COMPUTER=1", selecting yes in a dialogue that asks if they want to install software that likely has viruses, and point…

> where it can be reviewed > Critically, there must be time for someone to review By who? No one at npm is reviewing anything. "Someone" is doing a lot of work here. Linux distributions have trusted maintainers who are responsible for their packages. People who cared enough to figure out PGP and set up an actual web of trust. That's where the verification happens. All these programming language package managers have…

As discussed elsewhere in this forum, these exploits are being found by security companies in the first few days after they're published, that's just already too late. For example, the auditor who made the very post that we're discussing! For another, many security-focused AI companies have automated checks on NPM packages. Many people are implementing it on their end by having their client wait seven days before pulling new packages, but that's O(N) rather than O(1), and it's not evenly spread.

If no one reviews it and it still gets out, then we can address it then, but that seems much less likely.

Ideally, the solution is that all of these language package managers need to get serious and have maintainers, but lacking that, at least having the waiting period be built into the server instead of the client is a clear win.

Re: Malicious npm packages detected across Red Hat Cloud Services

#370

Post by eranation »

doctorpangloss wrote: post #333
eranation wrote: post #331

Earlier quoted context omitted.

I don't agree that nobody is adopting them. Can you please elaborate? - Most companies I know have a 24 hours (at least) cooldown via their Artifactory / Nexus. They have ways to bypass it for urgent CVEs - pnpm just adopted 24 hours cooldown as default, based on community feedback.

what is the difference between these two things from the point of view of how much work you have to do? - checking every update of every dependency to see if is a relevant urgent security update - checking every update of every dependency to see if it turns out to be a supply chain exploit am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly e…

It's a tradeoff, and I don't have hard data, but the cases where a reachable, exploitable, zero day CVE that requires an urgent immediate patch (usually unintentional vulnerability) vs complete dev machine / CI/CD takeover of a supply chain attack (malicious intent) - show that a 7 day cooldown (or even 24 hours) would be the safe choice. I should probably consider doing this research, didn't get to it yet.
Post reply on HN