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

581–590 of 1001 posts

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

#581

Post by lucideer »

Yeroc wrote: post #477
lucideer wrote: post #402

Earlier quoted context omitted.

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 wrap…

There are things that are potentially possible such as templating pom.xml build files or adjusting dependencies based on user properties (this that what you're suggesting?), but what you're describing is definitely not normal, or best practice in the ecosystem and shouldn't be presented as if it's normal practice.

Attackers don't need these practices to be normal, they just need them to be common enough (significant minority of)

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

#582

Post by cortesoft »

cycomanic wrote: post #446
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…

I've been arguing a couple of times that the 2 main reasons people want package management in languages are 1. Using an operating system with no package management 2. Poor developer discipline, i.e. developers always trying to use the latest version of a package. So now we have lots of poorly implemented language package managers, docker containers on top being used as another package management layer (even though th…

It doesn't matter if the operating system I personally use has a good package manager, I need to release it in a form that all the people using it can work with. There are a lot of OSes out there, with many package managers.

Even if we make every project create packages in every package manager, it still wouldn't add any auditing.

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

#583

Post by 0xbadcafebee »

gchamonlive wrote: post #2

We've seen many reports of supply chain attacks affecting NPM. Are these symptoms of operational complexity, which can affect any such service, or is there something fundamentally wrong with NPM?

With Javascript, yes, but also with all programming-language package managers and software development culture in general. There's too huge of an attack surface, and virtually no attack mitigation. It's a free for all. These are solvable problems, though. Distros have been doing it the right way for decades, and we could do it even better than that. But being lazy is easier. Until people are forced to improve - or there's some financial incentive - they don't.

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

#584

Post by olejorgenb »

floydnoel wrote: post #155
reactordev wrote: post #70

Earlier quoted context omitted.

Until you go get malware Supply chain attacks happen at every layer where there is package management or a vector onto the machine or into the code. What NPM should do if they really give a shit is start requiring 2FA to publish. Require a scan prior to publish. Sign the package with hard keys and signature. Verify all packages installed match signatures. Semver matching isn’t enough. CRC checks aren’t enough. This h…

NPM does require 2FA to publish. I would love a workaround! Isn't it funny that even here on HN, misinformation is constantly being spread?

> The malware includes a self-propagation mechanism through the NpmModule.updatePackage function. This function queries the NPM registry API to fetch up to 20 packages owned by the maintainer, then force-publishes patches to these packages.

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

#585

Post by TheDong »

parhamn wrote: post #548

For a large subset of packages (like the browser ones), as a layman, it seems feasible to do static analysis for: 1) fetch calls 2) obfuscation (like sketchy lookup tables and hex string construction) Like for (1) the hostname should be statically resolvable and immutable. So you can list the hostnames it fetches from as well. Is this feasible or am I underestimating the difficulty? Javascript seems to have no shorta…

There are many ways to "eval" in javascript, and static analysis can only work if that's also statically disallowed.

Unfortunately, eval is still used in a lot of code, so disabling it isn't trivially viable, and with eval present, detecting fetch calls and such statically becomes the halting problem.

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

#586

Post by tcoff91 »

gmueckl wrote: post #517
hermannj314 wrote: post #474

Earlier quoted context omitted.

Almost all software has a no warranty clause. I am not a lawyer but in pretty plain English every piece of software I have ever used has said exactly that I can fuck off if I expect it to work or do anything. To clarify - I dont think it is naive to assume the software is as-is with all responsibilities on the user since that is exactly what lawyers have made all software companies say that for over 50 years.

Product liability is coming for software. Warranty disclaimers in licenses will be rendered ineffective by the end of 2026 at the latest.

Source? An open source library is not necessarily a ‘product’ at all.

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

#587

Post by respondo2134 »

duped wrote: post #489
kelnos wrote: post #405

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 embed…

Personally, I go further than this and just never update dependencies unless the dependency has a bug that affects my usage of it. Vulnerabilities are included. It is insane to me how many developers update dependencies in a project regularly. You should almost never be updating dependencies, when you do it should be because it fixes a bug (including a security issue) that you have in your project, or a new feature t…

this seems to me to be trading one problem that might happen for one that is guaranteed: a very painful upgrade. Maybe you only do it once in a while but it will always suck.

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

#589

Post by respondo2134 »

kelnos wrote: post #546
duped wrote: post #489

Earlier quoted context omitted.

Personally, I go further than this and just never update dependencies unless the dependency has a bug that affects my usage of it. Vulnerabilities are included. It is insane to me how many developers update dependencies in a project regularly. You should almost never be updating dependencies, when you do it should be because it fixes a bug (including a security issue) that you have in your project, or a new feature t…

Fully disagree. The problem is that when you do need to upgrade, either for a bug fix, security fix, or new feature that you need/want, it's a lot easier to upgrade if your last upgrade was 3 months ago than if it was 3 years ago. This has bitten me so many times (usually at large orgs where policy is to be conservative about upgrades) that I can't even consider not upgrading all my dependencies at least once a quart…

yeah, I typically start any substantial development work with getting things up to date so you're not building on something you'll find out is already broken when you do get around to that painful upgrade.

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

#590

Post by const_cast »

bennyg wrote: post #466
Ajedi32 wrote: post #420

Earlier quoted context omitted.

If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.

Sounds like the job for an LLM tool to extract what's actually used from appropriately-licensed OSS modules and paste directly into codebases.

This is already a thing, compiled languages have been doing this for decades. This is just C++ templates with extra steps.
Post reply on HN