Another NPM Package Is Highjacked | Hacker News Reader

Another NPM Package Is Highjacked

blog.openreplay.com

13 pointsLiriel23 comments

I don't usually comment on HN, but I feel inclined for this article. The advice here is very poor and misleading and shows that the author has a weak understanding of the ecosystem.

Their suggestion is to lock your project dependencies in your package.json file, however this completely ignores the rest of the dependency graph that is brought in as a result of installing those packages, locked or not.

In my experience almost every CVE or exploited package was a dependency of a dependency of a dependency that I have no direct control over.

The only way to ensure dependencies of dependencies aren't changing without your knowledge is to use and commit a lock file.

Who the hell does not lock their dependencies with npm.lock or yarn.lock? The suggestion is practically useless. This is low-effort blogospam with very little concrete information; well congrats on reaching front page and drawing attention to the completely unrelated "Open Source Session Replay" you sell.

I find it offensive and unjustified that author specifically associates "React developers" with "Coders are so used to depending on 3rd party libraries that they can’t really work without them to the point where some of these libraries even define their career". The problem exists for anybody who uses any library ever, even a C programmer who uses a header only library can get hacked even in a worse way if he blindly updates his library to a new version. Because such a library can have conditionally compiled code that calls system APIs depending on the current OS. Browser is at least sandboxed to some extent. A better and more fair statement would be, that in frontend web development and NPM in particular there are usually too much dependencies and they are blindly updated too often.

The misguided assumption upon which this snobbery is based is that React developers and, say, C developers are different sets of people. Most developers are pragmatic and are probably going to use React or Vue to build a website in 2021 because they’re sensible choices of frameworks, not because they’re necessarily inexperienced.

It's certainly more prevalent on the front end, though. You'll never see a C/C++ job add looking for "libsodium developer" or "plibsys developer," however front end job postings are littered with "Angular dev" and "React dev" and will not consider anyone who's spent the last decade writing JavaScript but hasn't used whatever front-end button library is in use.

I honestly don't know what your system API point has to do with anything when we're talking about a distinct disadvantage to NPM specifically and the JS ecosystem generally.

Do you ever see job postings for C or C++ that only require you to know the language? Jobs are looking for domain specific skills, sometimes a framework implies such a domain like "React programmer"="frontend programmer", sometimes it's the other way around like "3d Effects programmer"="GLSL programmer". In all cases though, the bare language is never enough, no matter how many decades you used it, you have to have experience with special tools for your domain, be it frontend, graphics, operating systems, hardware or anything else.

Why do you think this is distinct disadvantage to NPM specifically? You can steal someones account and do the same with Rust crate for example, or Go package or even C/C++ header only library. It can get installed or updated to malicious version on user side in the same way, because everyone uses version ranges like "^" or "~" or equivalent. And if you're going to say everyone uses lockfiles, NPM also uses lockfiles for many years already.

Why don't we have signing keys for publishers yet?

Absolutely agree that it is disturbing that this isn't a priority.

Necessary, but still not sufficient - I suspect the attack model will just move to buying/stealing keys.

Still an improvement. Keys can be revoked and regenerated.

So can be the published packages? And the developer accounts' passwords?

Revoking the keys makes whatever existing artifacts and packages signed with old keys fail integrity checks.

Revoking the published packages and rotating compromised passwords should certainly also be done, but neither of those stop packages in mirrored or present in local caches from being used without further intervention (assuming your packaging ecosystem regularly verifies packages have valid signatures, which sadly I know ecosystems like NPM do not).

There are loads of signed malware: in fact, that's how you know it's of genuinely good quality.

We could, but those keys can be stolen as well. As long as the signing is, for example, done through an automated CI/CD, the keys would only work as a second stronger password.

What might work would be an interactive two factor authentication similar to how Microsoft or Google does it. Every time a release to the package repository was awaiting, the author would get push notification to their primary device and it would have to be approved manually.

Well, duh: the release of a package should require a confirmation from the authorized human, delivered via a safe channel.

https://sigstore.dev is infra for doing this similar to how SSL certs work.

Why don't we force two factor auth for publishers?

Npm is owned by Microsoft. If they forced 2FA on all npm publishers as you propose the anti-MSFT wing of the coding community would go ballistic convinced it was an evil master plan to extinguish open source forever.

I believe that this kind of issue is possible with most language specific package repositories. That combined with the fact that a lot of developers upgrade dependencies without giving it a lot of thought (newer is better) probably means that this will happen again.

Still, when I update packages on my Debian install, I am not worried at all about this kind of issue. That makes me wonder if and why Debian packages would be safer. I think that the following are reasons that I trust official Debian packages:

* it is a curated list of software: confidence in the quality of the software

* maintainers follow up on security issues: confidence in security issues being fixed in a timely manner

* packages are signed: confidence that package is created by a trusted maintainer

* trustworthy maintainers: not everyone can upload new versions of packages, it takes time to become a new maintainer

So it makes me wonder whether a similar concept of curated repositories for language specific package repositories would be useful or needed... am I the only one to think about this?

pinning dependencies to a specific version does not seem to be a workable and practical advice,

if everyone locked every single dependency wouldn't most 3rd party software be uninstallable?

for any moderately complex software conflicts will arise if they share dependencies.

Go modules does this, but uses a different algorithm and semantics.

I really think they have done a great job w.r.t. software supply chain security. I've been working on a post here going into detail https://verdverm.com/go-mods/

Could at least spellcheck the title before publishing

It's not a coincidence that these attacks are prevalent in the frontend world.

Most frontend developers are mere trend followers instead of hackers and have agreed to obtuse, over the top solutions because that is what the industry says. It has become the norm to have countless layers to show a simple checkbox tied to a boolean column in the db.

Just because everything is wrapped in one install command like create-react-app doesn't mean it's actually better.

Of course there are exceptions but the vast majority of designers and front end developers fall into this bucket.

The local business that contracted a website does not want a custom hand-rolled implementation of DOM manipulation to maintain. You’re not a “trend follower” for choosing an industry standard framework and it has nothing to do with your ability.

Reply on news.ycombinator.com