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

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

Post reply on HN
Print view View original

321–330 of 797 posts

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#321

Post by Yokohiii »

joshstrange wrote: post #187
blueflow wrote: post #176

Earlier quoted context omitted.

You are using the word "vendoring" differently than i do, i mean some kind of private fork of the repository.

You are using the word differently than everyone else I think. I’ve never heard someone using that word to mean maintain private forks. Then again, even private forks don’t protect you much more than package lock files and they are way more overhead IMHO. You still need some out-of-band process to pull upstream updates and aside from a built-in “cool down” (until you merge changes) I see that method as having a huge…

Vendoring literally just means grabbing the source code from origin and commit it to your repo after a review. The expectation that every repo has important regular updates for you is pure FOMO. And if I don't do random updates for fun, nothing will every break.

[redacted bullshit!]

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#322

Post by chuckadams »

sph wrote: post #7
vintagedave wrote: post #2

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

> It's not "node" or "Javascript" the problem, it's this convenient packaging model.

That and the package runtime runs with all the same privileges and capabilities as the thing you're building, which is pretty insane when you think about it. Why should npm know anything outside of the project root even exists, or be given the full set of environment variables without so much as a deny list, let alone an allow list? Of course if such restrictions are available, why limit them to npm?

The real problem is that the security model hasn't moved substantially since 1970. We already have all the tools to make things better, but they're still unportable and cumbersome to use, so hardly anything does.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#323

Post by dboreham »

vorticalbox wrote: post #218
kome wrote: post #97

why don't web devs just learn html and css properly, and maybe xslt for the really complex transformations then use vanilla js only when it's truly necessary? instead we've got this absolute mess of bloated, over-engineered junk code and ridiculously complicated module systems.

the issue is not that devs don't know what they are its that they don't pin packages if you run `npm i ramda` it will set this to "ramda": "^0.32.0" (as of comment) that ^ means install any version that is a feature or patch. so when a package is released with malware they bump version 0.32.1 and everyone just installs it on next npm i. pinning your deps "ramda": "0.32.0" completely removes the risk assuming the vers…

For context: ramada 0.32.0 isn't a concrete thing, in the sense that glibc 2.35 is. It really means "the latest ramada code because if you were to pin on this version it'll at some point stop working". glibc 2.35 never stops working.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#324

Post by codedokode »

amiga386 wrote: post #224
codedokode wrote: post #191

Does NPM use any automatic scanners? Just scanning for eval/new Function/base64 and other tokens often used by malware, and requiring a manual review, could already help. Also package manager should not run scripts.

Static scanning won't help. You can write this["eval"]() instead of eval(), therefore you can write this["e" + "v" + "a" + "l"](), and you can substitute (!![]+[])[!+[]+!+[]+!+[]] for "e", (![]+[])[+!+[]] for "a" (and so on: https://jsfuck.com/ ) In this Turing-equivalent world, you can only know what actually executes (e.g. eval, fetch) by actually executing all code in the package and then see what functions got ex…

Well, writing obfuscated code like ["e" + "v" + "a" + "l"]() is already a huge red flag for sending the package to manual review. While it might be impossible to detect all methods of obfuscation, we could start with known methods.

Also, detecting obfuscated code sounds like an interesting and challenging task.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#325

Post by BowBun »

Y_Y wrote: post #72
timgl wrote: post #4

co-founder of PostHog here. We were a victim of this attack. We had a bunch of packages published a couple of hours ago. The main packages/versions affected were: - posthog-node 4.18.1, 5.13.3 and 5.11.3 - posthog-js 1.297.3 - posthog-react-native 4.11.1 - posthog-docusaurus 2.0.6 We've rotated keys and passwords, unpublished all affected packages and have pushed new versions, so make sure you're on the latest versio…

> so make sure you're on the latest version of our SDKs. Probably even safer to not have been on the latest version in the first place. Or safer again not to use software this vulnerable.

As a user of Posthog, this statement is absurd: > Or safer again not to use software this vulnerable.

Nearly all software you use is susceptible to vulnerabilities, whether it's malicious or enterprise taking away your rights. It's in bad taste to make a comment about "not using software this vulnerable" when the issue was widespread in the ecosystem and the vendor is already being transparent about it. The alternative is you shame them into not sharing this information, and we're all worse for it.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#326

Post by vrighter »

bichiliad wrote: post #190
shortrounddev2 wrote: post #182

Earlier quoted context omitted.

it's interesting that staying up to date with your dependencies is considered a vulnerability in Node

Having a cooldown is different from never updating. I don’t think waiting a few days is a bad security practice in any environment, node or otherwise.

But only if most of everyone else doesn't do so.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#327

Post by JeremyNT »

PunchyHamster wrote: post #297
sph wrote: post #7

Earlier quoted context omitted.

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…

Rust (and really, any but JS) ecosystem have a bit more "due dilligence" applied everywhere; I don't doubt someone will try to namesquat but chance of success are far smaller > 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 cambrian explosion of dependencies to be a very good idea security-wise. There was no decision in case of C/C+…

> Rust (and really, any but JS) ecosystem have a bit more "due dilligence" applied everywhere; I don't doubt someone will try to namesquat but chance of success are far smaller

I really agree, and I feel like it's a culture difference. Javascript was (and remains) an appealing programming language for tinkerers and hobbyists, people who don't really have a lot of engineering experience. Node and npm rose to prominence as a wild west with lots of new developers unfamiliar with good practices, stuck with a programming environment that had few "batteries included," and at a time when supply chain attacks weren't yet on everybody's minds. The barriers to entry were low and, well, the ecosystem sort of reflected that. You can't wash that legacy away overnight.

Rust in contrast attracts a different audience because of the language's own design objectives.

Obviously none of this makes it immune, and you can YOLO install random dependencies in any programming language, but I don't think any language is ever going to suffer from this in quite the same way and to the same extent that JS has simply due to when and how the ecosystem evolved.

And really, even JS today is not JS of yesteryear. Sure there are lots of bad actors and these bad NPM packages sneak in, but also... how widely are all of them used? The maturation of and standardization on certain "batteries included" frameworks rather than ad hoc piecing stuff together has reduced the liklihood of going astray.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#328

Post by Yokohiii »

prmph wrote: post #202

There is no easy solution to these problems. The solutions that are effective also involve actually doing work, as developers, library authors, and package managers. But no, we want as much "convenience" as possible, so the issues continue. Developers and package authors should use a lockfile, pin their dependencies, be frugal about adding dependencies, and put any dependencies they do add through a basic inspection…

I think if you generally depend on npm packages, being frugal is hard, because every random package works against you.

Last time my perception was also that publishing sec is a weak point. If at least heavily used packages would be forced to do manual security steps for publishing, it would help quite a bit as long the measures a safe.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#329

Post by poulpy123 »

sph wrote: post #7
vintagedave wrote: post #2

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

> 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 cambrian explosion of dependencies to be a very good idea security-wise.

The safest code is the code that is not run. There is no lack of attacks targeting C/C++ code, and odin is just a hobby language for now.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#330

Post by larusso »

kibwen wrote: post #98
larusso wrote: post #67

Earlier quoted context omitted.

I agree partly. I love cargo and can’t understand why certain things like package namespaces and proof of ownership isn’t added at a minimum. I was mega annoyed when I had to move all our Java packages from jcenter, which was a mega easy setup and forget affair, to maven central. There I suddenly needed to register a group name (namespace mostly reverse domain) and proof that with a DNS entry. Then all packages have…

> But the fact that at least on npm it was possible that someone else grabs a package ID after an author pulled its packages is kind of alarming. Since your comment starts with commentary on crates.io, I'll note that this has never been possible crates.io. > Dependency confusion attacks are still possible on cargo because the whole - vs _ as delimiter wasn’t settled in the beginning. I don't think this has ever been…

You are right. I remembered it wrong.

https://rust-lang.github.io/rfcs/0940-hyphens-considered-har...

Was from 2015 and the other discussions I remember were around default style and that cargo already blocks a crate when normalized name is equal.

Post reply on HN