So people using only distro provided dependencies were indeed right all along. ;-)
Shai-Hulud Returns: Over 300 NPM Packages Infected
661–670 of 797 posts
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#662Earlier quoted context omitted.
Look at the diff in the article, it shows the “inject” part: the malicious file is added to the “preinstall” attribute in the package.json.
I still don't get it. Like, I understand that if you apply the diff you get infected. But... why would you apply the diff? How would you trick me to apply that diff to my package?
Someone could be tricked into giving their npm credentials to the attacker (e.g. via a phishing email), and then the attacker publishes new versions of their packages with the malicious diff. Then when the infected packages are installed, npm runs the malicious preinstall script which harvests secrets from the new machine, and if these include an npm token the worm can see which packages it has access to publish, and infect them too to continue spreading.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#663Earlier quoted context omitted.
Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.
That is indeed what one should do IMO. We've known for a long time now in the ops world that keeping versions stable is a good way to reduce issues, and it seems to me that the same principle applies quite well to software dev. I've never found the "but then upgrading is more of a pain" argument to be persuasive, as it seems to be equally a pain to upgrade whether you do it once every six months or once every six yea…
The 'pain' comes from breaking changes, at worst if you delay you're going to ingest the same quantity of changes, and at best you might skip some short-lived ideas.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#664Serious question: should someone develop new technologies using Node any more? A short time ago, I started a frontend in Astro for a SaaS startup I'm building with a friend. Astro is beautiful. But it's build on Node. And every time I update the versions of my dependencies I feel terrified I am bringing something into my server I don't know about. I just keep reading more and more stories about dangerous npm packages…
It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…
I don’t get this
I installed the package, obviously I intend to run it. How does getting pwned once I run it manually differ from getting pwned once I install it? I’m still getting pwned
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#665Both of these attacks have used trufflehog. Is there an out of the box way to block that executable by name or signature?
I'd say an alternative question is "how can we stop storing secrets in source control" so then tools like Trufflehog can't find them :)
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#666Earlier quoted context omitted.
Thank you for the clarification, that's exactly what I was trying to say :). Perhaps another way to phrase this: in Rust, you spend more time telling the compiler how your code is expected to work (making the borrow checker happy, adding sync traits on objects you "know" are thread safe because of how you use them or assurances the underlying hardware provides, etc etc etc). In return, the compiler does a lot of work…
I don't spend significant time making the borrow checker happy, because I learned how to write C++ that works.
¯\_(ツ)_/¯ I'd like to lean into that "YMMV" in my post, I'm coming from low level C that interacts with hardware, can't really speak to higher-level C++.
Some things in Rust just don't translate to the way you'd do them in C - e.x. using different types to say if a GPIO pin is input or output adds a ton of boiler plate, but lets the compiler assure you don't mistakenly try and use a pin configured as an input for output.
In general, the whole zero sized types paradigm in Rust leads to way more lines of code to accomplish the same thing (it all ends up compiled out in the end though).
For embedded, I'll stand by what I said: it takes longer to write idiomatic Rust but you are more likely to get functionally correct code in the end.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#667ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…
There were some recent posts I saw about "dependency cooldowns", which seem to be what you're referring to in item 2. The idea really resonated with me. That said, I hard pin all our dependencies and get dependabot alerts and then look into updates manually. Not sure if I'm a rube or if that's good practice.
That's good practice. God knows how many times I've been bitten by npm packages breaking on minor or even patch version changes, even when proudly proclaiming to use semver
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#668I see a bunch of postman packages vulnerable. Does that mean the desktop application is compromised (oof)?
Postman posted a blog entry about the event:
https://blog.postman.com/engineering/shai-hulud-2-0-npm-supp...
"Our security engineering team is investigating the matter and thus far has concluded that while some public Postman NPM packages were infected, (1) Postman as an app is not compromised, and (2) our production cloud services are also not compromised."
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#669Earlier quoted context omitted.
Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.
The arguments for doing frequent releases partially apply to upgrading dependencies. Upgrading gets harder the longer you put it off. It’s better to do it on a regular schedule, so there are fewer changes at once and it preserves knowledge about how to do it. A cooldown is a good idea, though.
There's another variable, though, which is how valuable "engineering time now" is vs. "engineering time later."
Certainly, having a regular/automated update schedule may take less clock time in total (due to preserved knowledge etc.), and incur less long-term risk, than deferring updates until a giant, risky multi-version multi-dependency bump months or years down the road.
But if you have limited engineering resources (especially for a bootstrapped or cost-conscious company), or if the risks of outages now are much greater than the risks of outages later (say, once you're 5 years in and have much broader knowledge on your engineering team), then the calculus may very well shift towards freezing now, upgrading later.
And in a world where supply chain attacks will get far more subtle than Shai-Hulud, especially with AI-generated payloads that can evolve as worms spread to avoid detection, and may not require build-time scripting but defer their behavior to when called by your code - macro-level slowness isn't necessarily a bad thing.
(It should go without saying that if you choose to freeze things, you should subscribe to security notification services that can tell you when a security update does release for a core server-side library, particularly for things like SQL injection vulnerabilities, and that your team needs the discipline to prioritize these alerts.)
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#670Earlier quoted context omitted.
Indeed, Rust's supply chains story is an absolute horror, and there are countless articles explaining what should be done instead (e.g. https://kerkour.com/rust-stdx ) TL;DR: ditch crates.io and copy Go with decentralized packages based directly on and an extended standard library. Centralized package managers only add a layer of obfuscation that attackers can use to their advantage. On the other hand, C / C++ style…
> countless articles explaining what should be done instead (e.g. https://kerkour.com/rust-stdx ) Don't make me tap the sign: https://news.ycombinator.com/item?id=41727085#41727410 > Centralized package managers only add a layer of obfuscation that attackers can use to their advantage. They add a layer of convenience. C/C++ are missing that convenience because they aren't as composable and have a long tail of pre-pac…
Or from another angle, dpkg/apt is the package manager for C/C++ ...