Using npm is like russian roulette. Someday it makes your head hurt really bad!
Embedded malware in RC (NPM package)
11–20 of 117 posts
Re: Embedded malware in RC (NPM package)
#12I checked the readme of both those packages and I can't for the life of me understand why would anyone use either of them. Why the fuck do all these leftpad is-even hello-world tic-tac-toe packages have millions of downloads?
Command line argument parsing and config loading both seem like very sensible library abstractions to me. This isn’t leftpad.
Command line argument parsing and config loading both seem like something that the standard library should provide.
Re: Embedded malware in RC (NPM package)
#13If you're interested in preventing this sort of thing, I'd appreciate comments on this [RFC]( https://github.com/npm/rfcs/pull/488 ) I just submitted to npm to make install scripts opt-in instead of default behavior . While of course not perfect, this simple change would certainly go a long way in increasing the difficulty in creating these sorts of attacks, as right now as long as a computer even installs the packag…
Problem is, as someone mentioned in the GitHub thread as well, people just press OK, especially if it's a transitive dependency.
Re: Embedded malware in RC (NPM package)
#14If you're interested in preventing this sort of thing, I'd appreciate comments on this [RFC]( https://github.com/npm/rfcs/pull/488 ) I just submitted to npm to make install scripts opt-in instead of default behavior . While of course not perfect, this simple change would certainly go a long way in increasing the difficulty in creating these sorts of attacks, as right now as long as a computer even installs the packag…
Your comments on the RFC cover this, but I want to highlight a two things:
1) The vast majority of packages on npm don't require install scripts to work.
2) Many of them that currently include install scripts are just ads asking people to contribute code or money to their project.
Re: Embedded malware in RC (NPM package)
#15I checked the readme of both those packages and I can't for the life of me understand why would anyone use either of them. Why the fuck do all these leftpad is-even hello-world tic-tac-toe packages have millions of downloads?
Command line argument parsing and config loading both seem like very sensible library abstractions to me. This isn’t leftpad.
>Command line argument parsing
20-30 LoC maybe. `process.argv.slice(2).forEach(str => ... )`.
there is no access to the raw command-line invocation, sadly, so you really can't really do anything fancier than that.
>config loading
that thing "RC" package does - looking up the config file in random locations - is really strange to me. aren't you the one in control of where it is stored?
Re: Embedded malware in RC (NPM package)
#16If you're interested in preventing this sort of thing, I'd appreciate comments on this [RFC]( https://github.com/npm/rfcs/pull/488 ) I just submitted to npm to make install scripts opt-in instead of default behavior . While of course not perfect, this simple change would certainly go a long way in increasing the difficulty in creating these sorts of attacks, as right now as long as a computer even installs the packag…
Problem is, as someone mentioned in the GitHub thread as well, people just press OK, especially if it's a transitive dependency.
I don't think anyone is claiming making install script opt-in will fix all the problems. But adding any friction discourages the behavior. And if the norm changes, it's reasonable to believe package maintainers will start opting for dependencies that don't require install scripts. Thus further encouraging people to not include them with their packages.
Re: Embedded malware in RC (NPM package)
#17If you're interested in preventing this sort of thing, I'd appreciate comments on this [RFC]( https://github.com/npm/rfcs/pull/488 ) I just submitted to npm to make install scripts opt-in instead of default behavior . While of course not perfect, this simple change would certainly go a long way in increasing the difficulty in creating these sorts of attacks, as right now as long as a computer even installs the packag…
Problem is, as someone mentioned in the GitHub thread as well, people just press OK, especially if it's a transitive dependency.
I've answered this on GitHub, but will provide an answer here too. Packages aren't like end-user software, for two important reasons:
1. The people involved are developers using development components, who are much better equipped to understand an installation failure and take proper action than an end user who is just trying to click through to play a video game or something. But more importantly:
2. The vast majority of the installs happen on automated machines (like CI), where you definitely want to fail when something drastically different happens like a new package is all of a sudden running a script. The tests would fail, you would look at the reason, it would be because some weird script is about to run on the machine, and you'd adjust your PR accordingly. This allows multiple levels of consideration: 1) the original author deciding to do something about the failed install (even if it's just appending the flag and not thinking about it), and 2) the PR reviewer having code-as-data evidence that this code change would mean new foreign code not represented in the commits will be running on their machines. This is huge.
The other important point about this is that packages precisely have different risk models depending on whether you are installing things locally or on production machines, where a malicious package could be catastrophic. That's why the RFC allows you to have individual user configuration where you explicitly allow certain packages "from now on" (which is I think the way most people want to think about this: the first time you install something and it warns you and you look into it, but from then on you say "this one is good"). On the other hand, the actual scripts and repository have no such configuration and thus require the installation to include the specific flags, again, clearly documenting the expected results of a seemingly innocent process that can actually currently have bad consequences.
Re: Embedded malware in RC (NPM package)
#18Earlier quoted context omitted.
Command line argument parsing and config loading both seem like very sensible library abstractions to me. This isn’t leftpad.
Command line argument parsing and config loading both seem like something that the standard library should provide.
Ok, now, what languages beside Python and Go provide Command line argument parsing? And Go doesn't do that in a `professional` way. You either write your own, which can easily turn into a clusterfuck or use a third party library. Even in Go, people use cobra[1]. Also embedding a lot of functionality in a standard library isn't great as well, because if some vulnerability is found, it's really hard to patch it, because you need to push versions and (for example on Linux) some distro maintainers won't push it for `stability` etc. A standard library should provide basic functionality (in most general areas), but not very advanced one.
Re: Embedded malware in RC (NPM package)
#19Earlier quoted context omitted.
Chained dependencies? If you can fool one popular package to depend on you, you ride their coattails. And perhaps some faked download numbers to lend an air of authenticity.
Maybe we need to hold the popular packages accountable for stuff like this.
Before we go mobbing innocent open source devs on Twitter, it'd be great to know how far NPM has progressed on 2FA. Up until 2018 NPM didn't have 2FA at all. They just introduced it. It'd be nice if they could give some kind of progress report on how widely adopted it's become. Ideally it should be required for publishing packages. Or at the very least, it'd be great to have some transparency about which package authors are actually using it, who aren't, and who's delegated their authorization to some other vendor like Travis -- so we as users can make our own informed choices about risk. It'd also be useful to have charts that log dependency gravity over time since an important question in situations like this is: did RC and Coa go from 70k to 17m users yesterday? Or have they been established for a long time?
Re: Embedded malware in RC (NPM package)
#20And yet again, twice in a row this time. Note how the referenced Virustotal result has 40+ detections [1]. I'm still wondering why info like this isn't used by Pypi and NPM. Chocolatey has Virustotal integration for all releases. And it's not like Virustotal is the only option, there is Cape [2] for dynamic execution, Metadefender, and Intezer Analyze just to name a few. Really confusing for such a vital supply chain…
It’s not clear that this would be useful; at least for the coa package, the DLL was downloaded dynamically via a script, so NPM would not have been able to detect it unless the script itself was flagged. Not sure what Chocolatey does, but it’s also hard to threshold on VirusTotal when there are a lot of FPs by random vendors.
I think Chocolatey has manual screens when there are more than 5 detections, but not entirely sure