Live data from Hacker News

NPM flooded with malicious packages downloaded more than 86k times

arstechnica.com

211–220 of 308 posts

Re: NPM flooded with malicious packages downloaded more than 86k times

#211

Given the recent npm attacks, is it even safe to develop using npm. Whenever I start a react project, it downloads hundreds of additional packages which I have mo idea about what they do. As a developer who has learnt programming as a hobby, is it better to stick to some other safe ways to develop front end like thyme leaf or plain js or something else. When I build backend in flask or Django, I specifically type the…

Just a heads up that Pypi isn't immune from the same attack, with "Pypi supply chain attack" into Google revealing a (much smaller) number of packages that turned out to be malware. Some were not misspellings either, with one being a legitimate package that got hacked via GitHub Actions and a malicious payload added to the otherwise legitimate package.

No language ecosystem is but NPM/Node still encourages this idea (borrowed elsewhere and interpreted poorly) that everything must be its own tiny package and that it's acceptable to author libraries consisting of thousands of transitive dependencies from potentially dubious sources. Just this week I saw one (unmaintained dependency of a popular package) which consisted of a list of a dozen SQL operators. Anywhere else you would just write the damn code, maybe add a comment that these are the SQL-92 operators and be done with it literally forever. But in Node land that would be viewed as an antipattern which only another package can fix. It's a security and maintenance nightmare that can only be explained by laziness and outright stupidity.

Re: NPM flooded with malicious packages downloaded more than 86k times

#212
post #205

Earlier quoted context omitted.

Deno solves this, it's not a JavaScript Issue, it's a Node.JS / NPM issue.

How does Deno solve this? Genuine question by the way. I'm not trying to be snarky.

It provides a runtime, that sandboxes your application and requires you to give explicit permissions for file system operations and network requests.

This limits the attack surface, when it comes to installing malicious dependencies, that npm happily installs for you.

So yes, I was wrong and my previous comment a hyperbole. A big problem is npm, and not JavaScript.

My point about the staggering amount of dependencies still holds though.

Re: NPM flooded with malicious packages downloaded more than 86k times

#213

I feel super uneasy developing Software with Angular, Vue or any framework using npm. The amount of dependencies these frameworks take is absolutely staggering. And just by looking at the dependency tree and thousands of packages in my node_modules folder, it is a disaster waiting to happen. You are basically one phishing attack on a poor open source developer away from getting compromised. To me the entire JavaScrip…

Go kinda solves this by using repo links instead of package names. This forces you to go through the repo and copy paste the url (instead of manually typing it out), but it's not bulletproof I guess.

Re: NPM flooded with malicious packages downloaded more than 86k times

#214
post #75

Earlier quoted context omitted.

> That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways? I won't execute that code directly on my machine. I will always execute it inside the Docker container. Why do you want to run commands like `vite` or `eslint` directly on your machine? Why do they need access to anything outside the current directory?

I get this but then in practice the only actually valuable stuff on my computer is... the code and data in my dev containers. Everything else I can download off the Internet for free at any time.

This kind of mentality, and "seems a bit excessive to sandbox a command that really just downloads arbitrary code", is why the JS ecosystem is so prone to credential theft. It's actually insane to read stuff like that said out loud.

Re: NPM flooded with malicious packages downloaded more than 86k times

#215
post #206

I always wondered why people found it acceptable to just run npm on their systems for anything they do, and have it download anything on any build. Coming from "make" with repeatable and predictable builds, I was appalled that you run this thing and you have no idea what it will download and what it will produce. Could be something different the next time you run it! Who knows! I also found it bizarre that even for t…

> entire npm setups inside docker containers Did you then spend a month or two inspecting that setup? Did you do that after every dependency upgrade? Also both NPM and PNPM already freeze dependencies for you by default without any arcane docker setups.

> Did you then spend a month or two inspecting that setup? Did you do that after every dependency upgrade?

TBH, I never updated some of the setups. What's the point? Their job was to generate a CSS. Why would I want to upgrade dependencies or inspect that setup?

> arcane docker setups

I take issue with "arcane" — I have much more "arcane" setups than these :-)

Re: NPM flooded with malicious packages downloaded more than 86k times

#216
post #4

>When you run npm install, npm doesn't just download packages. It executes code. Specifically, it runs lifecycle scripts defined in package.json - preinstall, install, and postinstall hooks. What's the legitimate use case for a package install being allowed to run arbitrary commands on your computer? Quote is from the researchers report https://www.koi.ai/blog/phantomraven-npm-malware-hidden-in-i... edit: I was think…

There's nothing inherently wrong with that. The problem is npm allows any random person to upload packages. It's completely untrusted. Contrast that with Linux distributions which have actual maintainers who take responsibility for their packages. They don't generally allow malware to make it into the official software repositories. In many cases they went as far as meeting each other in person just to set up a decentralized root of trust with PGP. It's so much better and more trustworthy.

The truth is npm, pip, rubygems, cargo and all the other programming language package managers are just fancier versions of the silly installation instructions you often find in README files that tell people to curl some script and pipe it into bash.

Re: NPM flooded with malicious packages downloaded more than 86k times

#219
post #207

Earlier quoted context omitted.

This isn't just "imperfect", it's so deeply flawed that the next minor "mutation" of supply chain attack tactics is guaranteed to wipe you out if you rely on it. It's just a matter of time, it could be tomorrow, next month, maybe a year from now. Setting up a fully containerized development environment doesn't take a lot of effort and will provide the benefits you think you're getting here - that would be the "imperf…

Unfortunately, the current way of how things work is, like you said, "deeply flawed". You will not change it in a few months, not even in a few years too. What you can do, however, is to adapt to current threats, the same way adversaries adapt to countermeasures. Fully secure setups do not exist, and even if one existed, it would probably become obsolete very quickly. Like James Mickens said, whatever you do, you sti…

Sorry, what I'm proposing here is far from binary but yes, I am gatekeeping the bare minimum. It has to be gatekept otherwise I'm afraid we'll enter a state of mass industry delusion where everyone thinks they're safe, "doing something", even "following industry best practices", but in reality all we're doing is: [1]

If a supply chain attack would be a serious incident for you then you need to take meaningful actions to protect yourself. I'm trying to hold "you" (proponents of this idea) accountable because I don't want you to rationalize all of these actions that leave you wide open to future attacks in known, preventable ways and then pretend nobody could've seen this coming when it blows up in our face.

It's not "good enough" - it's negligence because you know that the hole is there, you know that the hackers know about it, you know how trivial it is to exploit, and yet we're arguing whether leaving this known vector open is "good enough" instead of taking the obvious next step.

Containers are very far away from "fully secure" setup, they suffer from escape vulnerabilities far more often than VMs, but their benefit is that they're lightweight and minimally obtrusive (especially for web development) and these days the integration with IDEs is so good you probably won't even notice the difference after a few days of adjusting to the new workflow.

You end up trading a bit of convenience for a lot of security - you're going to be reasonably well protected for the foreseeable future because the likelihood of someone pulling off a supply chain attack and burning a container escape 0-day on it is really low.

That should be good enough for most and if your developer machine needs more protection than this, I'll take a guess and say that your production security requirements are such that they require security review of all your dependencies before using them anyway.

With a VM you would get even more security but you would have to sacrifice a lot more convenience, so given the resistance to the less intrusive option this isn't even worth discussing right now.

How can you not see the nuance?

[1] https://i.imgur.com/Zj6rwEK.jpeg

Re: NPM flooded with malicious packages downloaded more than 86k times

#220
post #206

I always wondered why people found it acceptable to just run npm on their systems for anything they do, and have it download anything on any build. Coming from "make" with repeatable and predictable builds, I was appalled that you run this thing and you have no idea what it will download and what it will produce. Could be something different the next time you run it! Who knows! I also found it bizarre that even for t…

The entire Front end dev seems like trust me bro Wild West to me. All feels like endless layers of duct tape. Which I guess in a way it is given the evolution of browsers
Post reply on HN