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

NPM flooded with malicious packages downloaded more than 86k times

arstechnica.com

Post reply on HN
Print view View original

281–290 of 308 posts

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

#281

Post by cleartext412 »

philipwhiuk wrote: post #235
j1elo wrote: post #6

Earlier quoted context omitted.

Easy example that I know of: the Mediasoup project is a library written in C++ for streaming video over the internet. It is published as a Node package and offers a JS API. Upon installing, it would just download the appropriate C++ sources and compile them on the spot. The project maintainers wanted to write code, not manage precompiled builds, so that was the most logical way of installing it. Note that a while ago…

Running a C compiler on everyone's machines to avoid a bit of work is extremely dumb.

Modern internet is build on premise of repeatedly running megabytes of javascript on everyone's machines to avoid a bit of work.

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

#282

Post by zbentley »

marcus_holmes wrote: post #136
devsda wrote: post #119

Earlier quoted context omitted.

Inspecting 10 layers of dependencies individually to install a popular tool or an lsp server is going to work once or twice. Eventually either complacency or fatigue sets in and the attacker wins. I think we need a different solution that fixes the dependency bloat or puts more safeguards around package publishing. The same goes for any other language with excessive third-party dependency requirements.

Agree. It's going to take a lot of people getting pwned to change these attitudes though

Why would attitudes change? The impact is diffused across a wide enough populace (precisely because ecosystems with weak community norms around dependency security are extremely popular) that the rate of “shaping up in response to a painful lesson” may remain lower than the rate of newcomers joining the community or the rate of new insecure dependencies proliferating to serve new needs brought about by new use cases brought about by growing popularity of a platform.

That’s not to say it’s hopeless. Rather, it’s more likely that widespread improvement will need to be centrally orchestrated rather than organic in response to hacks.

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

#283

Post by zbentley »

cutemonster wrote: post #117
bigstrat2003 wrote: post #98

Earlier quoted context omitted.

That's not a realistic solution. Nobody is going to stop using their machine for development just to get some security gains, it's way too much of a pain to do that.

It is a realistic solution.

Taking this more seriously than it perhaps deserves: if that’s true, why isn’t widespread adoption of this approach growing?

Whether or not it’s a good idea, “realistic” implies practicality, which could presumably be measured by whether people find it worthwhile to do the thing.

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

#285

Post by TZubiri »

ab_testing wrote: post #108

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…

Here's my black pill: Node in general is not safe.

The blurring of the client-server lines is a security risk. Very easy to expose the wrong thing; the language appeals to people who know 1 language (which correlates with lack of experience).

In my personal experience node projects developed under my supervision had very basic client-server boundary vulns 66.67% of the time. Empirically it's not great.

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

#286

Post by Intralexical »

ashishb wrote: post #58

Here's my `npm` command these days. It reduces the attack surface drastically. alias npm='docker run --rm -it -v ${PWD}:${PWD} --net=host --workdir=${PWD} node:25-bookworm-slim npm' - No access to my env vars - No access to anything outside my current directory (usually a JS project). - No access to my .bashrc or other files. Ref: https://ashishb.net/programming/run-tools-inside-docker/

You should probably put some quotes around `$PWD`:

  alias npm='docker run --rm -it -v "$PWD:$PWD" --net=host --workdir="$PWD" node:25-bookworm-slim npm'
...Does this always work? I don't use much JS. Doesn't NPM sometimes build against system libs, which could be different in the container?

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

#287

Post by IgorPartola »

exe34 wrote: post #175
IgorPartola wrote: post #137

Earlier quoted context omitted.

Hard. In npm land you install React and 900 other dependencies come with it. And how ok are you reviewing every single one of those scripts and manually running them? Not that it is good that this happens but realistically most people would just say “run all” and let it run instead of running each lifecycle script by hand.

the only way I'd use react in a project is to download the react.js build. I don't see why people want to download 900 dependencies.

I am people and I don’t want to download 900 dependencies. But if I want to use React or Vue or anything but the most trivial JS libraries or frameworks I am held hostage by the fact that their dependencies have dependencies.

Surely there are ways to just stick to absolute basics and you can get quite far with what is built in or some very small libraries, but I guess it depends on where you would be most productive.

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

#288

Post by Defletter »

lioeters wrote: post #190
Defletter wrote: post #134

Earlier quoted context omitted.

How does Bun avoid this? Or is it more that Bun provides things that you'd otherwise need a dependency for (eg: websockets)?

From a link mentioned elsewhere in the thread: > Unlike other npm clients, Bun does not execute arbitrary lifecycle scripts for installed dependencies, such as `postinstall` and `node-gyp` builds. These scripts represent a potential security risk, as they can execute arbitrary code on your machine. https://bun.com/docs/guides/install/trusted I've also found the Bun standard library is a nice curated set of features t…

Hmmm, it still has a pretty extensive default list of permitted npm packages, which wouldn't necessarily be a problem if there were a way to disable it, but I can't seem to find it.

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

#289

Post by nektro »

Defletter wrote: post #134
nektro wrote: post #113

Earlier quoted context omitted.

this is one of the less talked about benefits of using bun

How does Bun avoid this? Or is it more that Bun provides things that you'd otherwise need a dependency for (eg: websockets)?

the latter is what i was getting at yeah. updated list of standard library-esque functions implemented in native code so the need to reach to npm for a dependency happens far less often.

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

#290

Post by procaryote »

cogman10 wrote: post #277
procaryote wrote: post #180

Earlier quoted context omitted.

There's a culture of micro-dependencies. In c++, most people wouldn't publish a library that does the equivalent of (1 == value % 2). Even if they did, almost no one would use it. For npm, that library will not only exist, it will have several dependencies and millions of downloads

That increases the surface area, which is certainly bad. But that doesn't really mean the risk isn't similarly there for C++. A few years back, the university of Minnesota was banned from the kernel (are they still banned?) for testing this exact theory. They tried to figure out how hard it would be to inject an intentional CVE into the kernel. [1] https://www.bleepingcomputer.com/news/security/linux-bans-un...

Of course, it's a risk with any dependency, but for a small number of dependencies you're more likely to be able to do some level of vetting.

The university of Minnesota would have had a much easier time not getting caught if there had been a tree of thousands of independently maintained dependencies

Post reply on HN