I haven't dug into the specifics but technical props and nostalgia to the "self propagating" nature. Reminds of the OG "Worm" - the https://en.wikipedia.org/wiki/Morris_worm
Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
111–120 of 1001 posts
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#112When the left-pad debacle happened, one commenter here said of a well known npm maintainer something to the effect of that he's an "author of 600 npm packages, and 1200 lines of JavaScript". Not much has changed since then. The best counter-example I know is esbuild, which is a fully featured bundler/minifier/etc that has zero external dependencies except for the Go stdlib + one package maintained by the Go project i…
Part of the reason of my switch to using Go as my primary language is that there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x.
These kind of projects usually are pretty great because they aim to work with CGO_ENABLED=0 so the libs are very portable and work with different syscall backends.
Additionally I really like to go mod vendor my snapshot of dependencies which is great for short term fixes, but it won't fix the cause in the long run.
However, the go ecosystem is just as vulnerable here because of lack of signing off package updates. As long as there's no verification possible end-to-end when it comes to "who signed this package" then there's no way this will get better.
Additionally most supply chaib attacks focussed on the CI/CD infrastructure in the past, because they are just as broken with just as many problems. There needs to be a better CI/CD workflow where signing keys don't have to be available on the runners themselves, otherwise this will just shift the attack surface to a different location.
In my opinion the package managers are somewhat to blame here, too. They should encourage and mandate gpg signatures, and especially in git commits when they rely on git tags for distribution.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#113Earlier quoted context omitted.
Pause, you could write an HTML to markdown library in half a day? Like, 4 hours? Or 12? Either way damn
One that gets me 90% there would take me few hours, one that gets me 99% there few months, which is why eventually people would rather pull a dependency.
Or about 15 minutes with an LLM?
https://github.com/williamcotton/markdown-to-html-llm
;)Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#114Earlier quoted context omitted.
Object-capability model / capability-based security. Do not let code to have access to things it's not supposed to access. It's actually that simple. If you implemented a function which formats a string, it should not have access to `readFile`, for example. Retrofitting it into JS isn't possible, though, as language is way too dynamic - self-modifying code, reflection, etc, means there's no isolation between modules.…
People have tried this, but in practice it's quite hard to do because then you have to start treating individual functions as security boundaries - if you can't readFile, just find a function which does it for you. The situation gets better in monadic environments (can't readFile without the IO monad, and you cant' call anything which would read it).
Well, to me it looks like people are unreasonably eager to use "pathologically dynamic" languages like JS & Python, and it's an impossible problem in a highly dynamic environment where you can just randomly traverse and change objects.
Programming languages which are "static" (or, basically, sane) you can identify all imports of a module/library, and, basically, ban anything which isn't "pure" part of stdlib.
If your module needs to work with files, it will receive an object which lets it to work with files.
A lot of programming languages implement object-capability model: https://en.m.wikipedia.org/wiki/Object-capability_model it doesn't seem to be hard at all. It's just programmers have preference for shittier languages, just like they prefer C which doesn't even have language-level array bound checking (for a lack of a "dynamic array" concept on a language level).
I think it's sort of orthogonal to "pure functional" / monadic: if you have unrestricted imports you can import some shit like unsafePerformIO, right? You have another level of control, of course (i.e. you just need to ban unsafePerformIO and look for unlicensed IO) but I don't feel like ocap requires Haskell
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#115I'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…
Why is this inevitable? If you use only easily verifyable packages you’ve lost nothing. The whole concept of npm automatically executing postinstall scripts was fixed when my pnpm started asking me every time a new package wanted to do that.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#116Earlier quoted context omitted.
Don't they? I just went to crates.io and picked a random newly updated crate, which happened to be pixelfix, which fixes transparent pixels in pngs. It has six dependencies and hundreds of transient dependencies, may of which appear to be small and highly specific a la left-pad. https://crates.io/crates/pixelfix/0.1.1/dependencies Maybe this package isn't representative, but it feels pretty identical to the JS ecosys…
It depends on `image` which in turn depends on a number of crates to handle different file types. If you disable all `image` features, it only has like 5 dependencies left.
And all those 5 remaining dependencies have lots of dependencies of their own. What's your point?
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#117I'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…
Which mitigations specifically are in npm but not in crates.io?
As far as I know crates.io has everything that npm has, plus
- strictly immutable versions[1]
- fully automated and no human in the loop perpetual yanking
- no deletions ever
- a public and append only index
Go modules go even further and add automatic checksum verification per default and a cryptographic transparency log.
Contrast this with docker hub for example, where not even npm's basic properties hold.
So, it is more like
docker hub ⊂ npm ⊂ crates.io ⊂ Go modules
[1] Nowadays npm has this arguably too
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#118Earlier quoted context omitted.
AFAICT, the only thing this attack relies on, is the lack of scrutiny by developers when adding new dependencies. Unless this lack of scrutiny is exclusive to JavaScript ecosystem, then this attack could just as well have happened in Rust or Golang.
JavaScript does have some pretty insane dependency trees. Most other languages don’t have anywhere near that level of nestedness.
It's not possible for a language to have an insane dependency tree. That's an attribute of a codebase.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#119Earlier quoted context omitted.
I can tell a lot about a dev by the fact that they single out npm/js for this supply chain issue.
Just more engineering leaning than you. Actual engineers have to analyze their supply chains, and so makes sense they would be baffled by NPM dependency trees that utterly normal projects grow into in the JavaScript ecosystem.
Do you think companies using node don't analyze supply chains? That's nonsense. Have you cargo installed a rust app recently? This isn't just a js issue. This needs to be solved across the industry and npm frankly has done a horrible job at it. We let people with billions of downloads a month with recently changed password/2fa publish packages? Why don't we pool assets as a collective to scan newly published packages before they're allowed to be installed? These types of things really should exist across all package registries (and my really hot take is that we probably don't need a registry for every language, either!).