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

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

socket.dev

Post reply on HN
Print view View original

401–410 of 1001 posts

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#401

Post by 0cf8612b2e1e »

Rockslide wrote: post #328
simiones wrote: post #325

Earlier quoted context omitted.

No, this is just wrong. It might indeed use package-lock.json if it matches your node_modules (so that running `npm install` multiple times won't download new versions). But if you're cloning a repo off of GitHub and running npm install for the first time (which a CI setup might do), it will take the latest deps from package.json and update the package-lock.json - at least this is what I've found many responses onlin…

Well but the docs you cited don't match what you stated. You can delete node_modules and reinstall, it will never update the package-lock.json, you will always end up with the exact same versions as before. The package-lock updating happens when you change version numbers in the package.json file, but that is very much expected! So no, running npm install will not pull in new versions randomly.

The internet disagrees. NPM will gladly ignore and update lock files. There may exist a way to actually respect lock files, but the default mode of operation does not work as you would naively expect.

- NPM Install without modifying the package-lock.json https://www.mikestreety.co.uk/blog/npm-install-without-modif...

- Why does "npm install" rewrite package-lock.json? https://stackoverflow.com/questions/45022048/why-does-npm-in...

- npm - How to actually use package-lock.json for installing based on locked versions? https://stackoverflow.com/questions/47480617/npm-how-to-actu...

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#402

Post by lucideer »

Yeroc wrote: post #324
lucideer wrote: post #291

Earlier quoted context omitted.

> in JS land almost everyone uses lax dependency declarations They do, BUT. Dependency versioning schemes are much more strictly adhered to within JS land than in other ecosystems. PyPi is a mishmash of PEP 440, SemVer, some packages incorrectly using one in the format of the other, & none of the 3 necessarily adhering to the standard they've chosen. Other ecosystems are even worse. Also - some ecosystems (PyPi again…

> Maven land is full of plugins with automated pom.xml version templating that has effectively the same effect as lax versioning, but without any strict adherence to any kind of standard like semver. Please elaborate on this. I'm a long-time Java developer and have never once seen something akin to what you're describing here. Maven has support for version ranges but in practice it's very rarely used. I can expect a…

I'm not a Java (nor Kotlin) developer - I've only done a little Java project maintenance & even less Kotlin - I've mainly come at this as a tooling developer for dependency management & vulnerability remediation. But I have seen a LOT of varied maven-managed repos in that line of work (100s) and the approaches are wide - varied.

I know this is possible with custom plugins but I've mainly just seen it using maven wrapper & user properties.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#403

Post by neutrinobro »

Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

The lack of an easy method to automatically pull in and manage dependencies in C/C++ is starting to look a lot more like a feature than a bug now.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#404

Post by zwnow »

ncruces wrote: post #381
Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-…

Unfortunately that's almost the whole industry. Every software project I've seen has an uncountable amount of dependencies. No matter if npm, cargo, go packages, whatever you name.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#405

Post by kelnos »

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embedded malware.

One thing I was thinking of was sort of a "delayed" mode to updating my own dependencies. The idea is that when I want to update my dependencies, instead of updating to the absolute latest version available of everything, it updates to versions that were released no more than some configurable amount of time ago. As a maintainer, I could decide that a package that's been out in the wild for at least 6 weeks is less likely to have unnoticed malware in it than one that was released just yesterday.

Obviously this is not a perfect fix, as there's no guarantee that the delay time I specify is enough for any particular package. And I'd want the tool to present me with options sometimes: e.g. if my current version of a dep has a vulnerability, and the fix for it came out a few days ago, I might choose to update to it (better eliminate the known vulnerability than refuse to update for fear of an unknown one) rather than wait until it's older than my threshold.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#407

Post by jacques_chester »

lucideer wrote: post #81
codemonkey-zeta wrote: post #31

I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem. These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probab…

> I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. I see this odd take a lot - the automatic narrowing of the scope of an attack to the single ecosystem it occurred in most recently, without any real technical argument for doing so. What's especially concerning is I see this take in the security industry: mitigations put in place to…

Most of the biggest repositories already cooperate through the OpenSSF[0]. Last time I was involved in it, there were representatives from npm, PyPI, Maven Central, Crates and RubyGems. There's also been funding through OpenSSF's Alpha-Omega program for a bunch of work across multiple ecosystems[1], including repos.

[0] https://github.com/ossf/wg-securing-software-repos

[1] https://alpha-omega.dev/grants/grantrecipients/

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#408

Post by kelnos »

ronsor wrote: post #331
thewebguyd wrote: post #320

Earlier quoted context omitted.

Why even put a package download count on it? Just require it for everything submitted to NPM. It's not hard.

Because then it's extra hassle and expense for new developers to publish a package, and we're trying to keep things decentralized.

Decentralized? This is a centralized package registry. There is nothing decentralized about it.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#410

Post by BrenBarn »

rlpb wrote: post #303
Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

There is another related growing problem in my recent observation. As a Debian Developer, when I try to audit upstream changes before pulling them in to Debian, I find a huge amount of noise from tooling, mostly pointless. This makes it very difficult to validate the actual changes being made. For example, an upstream bumps a version of a lint tool and/or changes style across the board. Often these are labelled "chor…

I agree with this and it's something I've encountered when just trying to understand a codebase or track down a bug. There's a bit of the tail wagging the dog as an increasing proportion of commits are "meta-code" that is just tweaking config, formatting, etc. to align with external tools (like linters).

> Unless there's actually reason to change code (eg. some genuine refactoring a human thinks is actually needed, a bug fix or new feature, a tool exposed a real bug, or at least some identifiable issue that might turn into a bug), it should be left alone.

The corollary to this is "Unless there's actually a need for new features that a new version provides, your existing dependency should be left alone". In other words things should not be automatically updated. This is unfortunately the crazy path we've gone down, where when Package X decides to upgrade, everyone believes that "the right thing to do" is for all its dependencies to also update to use that and so on down the line. As this snowballs it becomes difficult for any individual projects to hold the line and try to maintain a slow-moving, stable version of anything.

Post reply on HN