Live data from Hacker News

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

socket.dev

591–600 of 1001 posts

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

#591
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…

In practice, my experience is that this ends up with only old versions of things in the stable package repos. So many times I run into a bug, and then find out that the bug has been fixed in a newer version but it isn't updated in the stable repo. So now you end up pulling an update out of band, and you are in the same boat as before.

I don't know how you avoid this problem

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

#592
post #53
post #24

Earlier quoted context omitted.

> How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user? Zero? How many developers have plain-text tokens lying around on disk? Avoiding that been hammered into me from every developer more senior than me since I got involved with professional software development.

Isn't this quite hard to achieve on local systems, where you don't have a CI vault automation to help?

Most popular apps today have integrations to allow reading secrets from external programs. If not, they can take them from environment variables. Both those can then be loaded from a password manager, so the secret never lands on disk in plaintext.

Your program (or your shell) opens. It runs a program to ask the password manager for a secret. Your password manager prompts you to authorize unsealing the secret. You accept or deny. The secret is passed to the program that asked for it. Works very well with 1Password and tools like git, ssh, etc, or simply exporting the secret to an environment variable, either in a script or bashrc file.

Other programs also support OIDC, such as with git credential helper plugins, or aws sso auth.

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

#593

Earlier quoted context omitted.

Javascript is badly over-used and over-depended on. So many websites just display text and images, but have extremely heavy javascript libraries because that's what people know and that is part of the default, and because it enables all the tracking that powers the modern web. There's no benefit to the user, and we'd be better off without these sites existing if there were really no other choice but to use javascript…

> So many websites just display text and images Eh... This over-generalises a bit. That can be said of anything really, including native desktop applications.

Is that true? The things people use native desktop applications for nowadays tend to be exactly those which aren't just neat content displays. Spreadsheets, terminals, text-editors, CAD software, compilers, video games, photo-editing software. The only things I can think of that I use as just text/image displays are the file-explorer and image/media-viewer apps, of which there are really only a handful on any given OS.

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

#594
post #489
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…

Dependency hell exists at both ends. Too quick can bite you just as much as being too slow/lazy.

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

#595

I wonder who actually discovered this attack? Can we credit them? The phrasing in these posts is interesting, with some taking direct credit and others just acknowledging the incident. Aikido says: > We were alerted to a large-scale attack against npm... Socket says: > Socket.dev found compromised various CrowdStrike npm packages... Ox says: > Attackers slipped malicious code into new releases... Safety says: > The S…

Mackenzie here I work for Aikido. This is a classic example of the security community all playing a part. The very first notice of this was from a developer named Daniel Pereira. He alerted Socket who did the first review of the Malware and discovered 40 packages. After, Aikido discovered an additional 147 packages and the Crowdstrike packages. I'm not sure how Step found it but they were the first to really understa…

question how does your product help in these situations? I imagine it'd require for someone to report a compromised package, and then you guys could detect it in my codebase?

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

#596
post #558

Earlier quoted context omitted.

Isn't that what lockfiles are for? By default `npm i` downloads exactly the versions specified in your lockfile, and only resolves the latest versions matching the ranges specified in package.json if no lockfile exists. But CI/CD pipelines should definitely be using `npm ci` instead, which will only install packages from a lockfile and throws an error if it doesn't exist.

That and pin that damn version!

It’s still ridiculous to me that version pinning isn’t the default for npm.

The first thing I do for all of my projects is adding a .npmrc with save-exact=true

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

#597

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…

> The HTMX folks convinced me that I can get REALLY far without any JavaScript

HTMX is JavaScript.

Unless you meant your own JavaScript.

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

#598
post #541

Earlier quoted context omitted.

Copy-paste more.

I guess this is a joke, but imo it shouldn't be.

Not entirely a joke actually. For example, I have worked at a large corp where dependencies were high discouraged. For example lodash was not used in the codebase I was working on and if you really needed something from lodash you were encouraged to copy-paste the function. This won't work for large libraries of course but the copy-paste-first mentality is not a bad one.

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

#599
post #553

Earlier quoted context omitted.

Sure, and I do that whenever I can. But I'm not going to write my own react, or even my own react-hook-form. I'm not going to rewrite stripe-js. Looking through my 16 direct dependencies -- that pull in a total of 653 packages, jesus christ -- there's only one of them that I'd consider writing myself (js-cookie) in order to reduce my dependency count. The rest would be a maintenance burden that I shouldn't have to ta…

There's this defense mechanism that I don't know how it's called, but when someone takes a criticism to the extreme to complain about it being unfeasible. Criticism: "You should shower every day" Defense: "OH, maybe I should shower every hour, to the point where my skin dries and I can't get my work done because I'm in the shower all day." No, there's a pretty standard way of doing things that you can care to learn,…

Reductio ad Absurdum may be what you're thinking of, but Straw Man might also apply. Funny enough the responder didn't actually do what you said. They stated of the 600+ dependencies they counted there was only one they felt comfortable implementing themselves. Your accusation of them taking your statement to the extreme is reverse straw man rhetoric; you're misrepresenting their argument as extreme or absurd when it’s actually not.

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

#600
It's probably not trivial to implement and there's already a bunch of problems that need solving (e.g., trusting keys etc.) but... I think that if we had some sort of lightweight code provenance (on top of my head commits are signed from known/trusted keys, releases are signed by known keys, installing signed packages requires verification), we could probably make it somewhat harder to introduce malicious changes.

Edit: It looks like there's already something similar using sigstore in npm https://docs.npmjs.com/generating-provenance-statements#abou.... My understanding is that its use is not widespread though and it's mostly used to verify the publisher.

Post reply on HN