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

331–340 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#331

Post by eranation »

doctorpangloss wrote: post #309
eranation wrote: post #234

Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…

> Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, by now, you should have received the feedback about why cooldowns don't make sense and why nobody is adopting them. look, you are writing an expression of the reason why right there.

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.

Re: Malicious npm packages detected across Red Hat Cloud Services

#332

Post by nicogentile »

eranation wrote: post #330
Normal_gaussian wrote: post #319

Earlier quoted context omitted.

> Changing your own car's oil is actually not that hard It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance. > Think of QR codes, people hardly use…

That group of people is the loosely affiliated people called "vibe coders". Even to get them to install depsguard is a challenge. I just ask them to point Claude to depsguard or cooldowns and follow the instructions (to save the tokens, of course Claude can figure it what needs to be done on its own) The issue is that Claude Code also will be super happy to npm install axios / tanstack etc unless you explicitly tell…

[flagged]

Re: Malicious npm packages detected across Red Hat Cloud Services

#333

Post by doctorpangloss »

eranation wrote: post #331
doctorpangloss wrote: post #309

Earlier quoted context omitted.

> Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, by now, you should have received the feedback about why cooldowns don't make sense and why nobody is adopting them. look, you are writing an expression of the reason why right there.

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 exploited - either by using known vulnerable software or from supply chain attacked software.

Re: Malicious npm packages detected across Red Hat Cloud Services

#334

Post by nafey »

skydhash wrote: post #260
nafey wrote: post #214

Earlier quoted context omitted.

The problem is that node.js doesn't have a good standard library so one must rely on external packages to build even basic apps.

Can you tell us what exactly is missing? A network api? Process execution? IO? Math?

From this we can see a few patterns: https://www.npmleaderboard.org/

Node.js doesn't have good support for regex, handling files, streams, serving static html, routing, operations on lists/dicts.

Re: Malicious npm packages detected across Red Hat Cloud Services

#335

Post by spockz »

insanitybit wrote: post #135

Just some suggestions: 1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs. 2. Anywhere you have `npm install` or `npm test` or anything where code executes , that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and tes…

Should we instead of these cooldowns just run builds in isolated contexts?

I’m running a maven proxy locally. All builds happen inside containers. I only use public repos for python, npm, and go. So these builds happen also in containers but don’t need a repository proxy.

Re: Malicious npm packages detected across Red Hat Cloud Services

#336

Post by zwily »

user3939382 wrote: post #267
vinnymac wrote: post #159

Earlier quoted context omitted.

It’s on by default in yarn 4 too now, but pnpm was the first to market that default minimum gate. https://github.com/yarnpkg/berry/pull/7135

If this were a universal default, would the strategy defeat itself?

Even if everyone used it, the security scanners would still have time to do their static analysis of new packages. Basically, all the clients implementing a delay would create a de facto quarantine status for new packages so they can be examined before everyone starts installing them. (Why npm doesn't just implement that themselves, I do not know.)

Re: Malicious npm packages detected across Red Hat Cloud Services

#337

Post by Uvix »

Pxtl wrote: post #194
Romario77 wrote: post #167

Earlier quoted context omitted.

I think another thing that affects security is that in javascript culture people often tie to the latest version instead of concrete version. This makes it so an update to a popular library can compromise a huge number of packages that depend on it. In Java for example almost all packages specify a concrete version, even if someone compromises the latest the blast radius is usually pretty small.

MS Nuget is also lock-by-default. Latest-by-default should be considered harmful unless the package manager is directly vouching for the veracity and reputability of the packages.

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.

Re: Malicious npm packages detected across Red Hat Cloud Services

#338

Post by j1elo »

insanitybit wrote: post #303
j1elo wrote: post #259

Earlier quoted context omitted.

What is being said is that a new flag like '--minimum-release-age' would take, realistically speaking, tops 4 hours to implement (without AI assistance), plus a good 1 week of thorough testing, and maybe a 1 month period of progressive deployment. Come on, let's give it a total of 1.5 months, for good measure. Of course this should have been started since the beginning of the major recent stream of supply chain attac…

Have you ever managed software as critical and ubiquitous as npm?

Not infra, but final product. I know, corporations move slow. But when there is a critical issue, and an actual desire to solve it from someone in a suit, suddenly turns out that the cogs were always able to speed up and move fast...

Re: Malicious npm packages detected across Red Hat Cloud Services

#339

Post by tetha »

m4rtink wrote: post #143
nailer wrote: post #102

Earlier quoted context omitted.

I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong. So, explicitly: - pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer (limited) - Maven ...all allow scripts. We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager. npm shouldn't…

If DNF/RPM is used there will often be a separate distro maintainer that should ideally review any changes coming from the upstream before pulling them into the distribution. Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack. Definitely not bulletproof but still IMHO more robust than "Lets…

Also the APT and RPM world lets packages sit for a long time - those are called "testing" and "unstable" in the Debian world. It's slow, but it seems hard to move intentional exploits with short-term payoffs through as far as we can see.

That's also why I am actively moving a fundamental and important internal service we have to just use python dependencies packaged in Debian stable packages. Sure, it may be a year or two behind in features, I may loose a nice debugging tool or two, but it is a very stable footprint, has security updates, breaks rarely. For ops-internal scripting and tooling, it's good.

Re: Malicious npm packages detected across Red Hat Cloud Services

#340

Post by make3 »

eranation wrote: post #234

Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…

theoretical question, do cooldowns still work if everyone has them?
Post reply on HN