12 ms·

Embedded malware in RC (NPM package)

140 points by hjek 5y ago

hjek 5y ago
More info: https://therecord.media/malware-found-in-coa-and-rc-two-npm-packages-with-23m-weekly-downloads/ https://therecord.media/malware-found-in-coa-and-rc-two-npm-...
- bluefox 5y ago
  Thanks. > Since then, the npm security team has removed all the compromised coa and rc versions to prevent developers from accidentally infecting themselves. Removing all trace of evidence is not something "security teams" should do. Instead of sweeping security incidents under the rug (where twitterverse resides), they should at least mention the existence of these versions and that they contain malware on the package page.
  - bqkJoKocJz9jz 5y ago
    They posted the [version diffs] (https://my.diffend.io/npm/coa/2.0.2/2.0.4)in https://my.diffend.io/npm/coa/2.0.2/2.0.4)in the article. Not sure if this site catches all the changes though.
greenyoda 5y ago
See also the ongoing discussion about malware in "Coa", another NPM package: https://news.ycombinator.com/item?id=29116878 https://news.ycombinator.com/item?id=29116878
- dang 5y ago
  Also recent: NPM package ‘ua-parser-JS’ with more than 7M weekly download is compromised - https://news.ycombinator.com/item?id=28962168 https://news.ycombinator.com/item?id=28962168 - Oct 2021 (141 comments)
schleck8 5y ago
And 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 component to be this easily abused. One of the highlights is when someone recently used NPM to spread ransomware via a fake Roblox API package.[3] [1] https://www.virustotal.com/gui/file/26451f7f6fe297adf6738295b1dcc70f7678434ef21d8b6aad5ec00beb8a72cf/detection https://www.virustotal.com/gui/file/26451f7f6fe297adf6738295... [2] https://github.com/kevoreilly/CAPEv2 https://github.com/kevoreilly/CAPEv2 [3] https://www.reddit.com/r/programming/comments/qgz0em/fake_npm_roblox_api_package_installs_ransomware/ https://www.reddit.com/r/programming/comments/qgz0em/fake_np...
- iancarroll 5y ago
  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.
  - schleck8 5y ago
    I think Chocolatey has manual screens when there are more than 5 detections, but not entirely sure
  - schemescape 5y ago
    Given that these attacks are becoming increasingly common, package registries could at least install each package (prior to publishing) in some isolated container or VM and then run some similar malware detection on the resulting file system. Honestly, I'm strongly considering moving away from the NPM ecosystem because it's clearly become a target for malware.
    - 5y ago
qwerty2021 5y ago
I 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?
- afavour 5y ago
  Command line argument parsing and config loading both seem like very sensible library abstractions to me. This isn’t leftpad.
  - havkd 5y ago
    Command line argument parsing and config loading both seem like something that the standard library should provide.
    - megumax 5y ago
      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. [1] https://github.com/spf13/cobra https://github.com/spf13/cobra
      - MrStonedOne 5y ago
        php
      - kitsunesoba 5y ago
        It's not part of the standard library, but Swift has the first-party ArgumentParser[0]. Other languages could use a similar model (though what "first party" means for JavaScript is unclear). [0]: https://github.com/apple/swift-argument-parser https://github.com/apple/swift-argument-parser
tolmasky 5y ago
If you're interested in preventing this sort of thing, I'd appreciate comments on this [RFC](https://github.com/npm/rfcs/pull/488 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 packages in question, not even running any code in the package, the malicious program has a chance at running. RFC: https://github.com/npm/rfcs/pull/488 https://github.com/npm/rfcs/pull/488 Related HN post: https://news.ycombinator.com/item?id=29122473 https://news.ycombinator.com/item?id=29122473
- chakkepolja 5y ago
  Problem is, as someone mentioned in the GitHub thread as well, people just press OK, especially if it's a transitive dependency.
  - Me1000 5y ago
    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.
  - tolmasky 5y ago
    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.
BonoboIO 5y ago
Using npm is like russian roulette. Someday it makes your head hurt really bad!
hn_throwaway_99 5y ago
One of the thing I wish was really much easier to do with NPM is, when running `npm update`, to only pick up the most recent compatible versions from X days ago. That is, for sensitive apps, I don't want to use versions that are less than, say, a month or so old unless I specifically override it. I want to stay up-to-date but not too bleeding edge, specifically to avoid situations like this.
- dane-pgp 5y ago
  That would be a big improvement, but I assume that people would override this check whenever they were updating a package to fix a minor accidental vulnerability that had been found in it (detected by an "npm audit"). An attacker who had control over an account would wait until just such a moment to add their own version which includes a much worse payload, and people would rush to download it, thinking they were just installing a fix for the minor vulnerability.
- beart 5y ago
  renovate bot can do this. set it to wait for x days before accepting a merge, and pin your versions so there's no chance to update by mistake.
rndhouse 5y ago
I've created Vouch in an attempt to address this problem: https://github.com/vouch-dev/vouch https://github.com/vouch-dev/vouch Vouch lets users create and share reviews for NPM packages. Project dependencies can then be checked against those reviews. Vouch uses extensions to interface with package ecosystems. It's simple to create a new extension. Extensions currently exist for NPM, PyPi, and Ansible Galaxy. I'm currently working on a website to index known reviews and publish official reviews. I hope you guys find it useful! Drop by the Matrix channel if you have any feedback to share: #vouch:matrix.org
- hjek 5y ago
  Sounds really interesting. I'm kinda scared to use npm right now to be honest. What dangers may be hidden deep in the dependency trees? But is a review of every update then done, because rc used to be a legit package?
  - rndhouse 5y ago
    A review corresponds to a particular version number. But the review process does not need to start from scratch with each version number increment. Reviews from previous versions can be leveraged to lessen the workload.
- yjftsjthsd-h 5y ago
  I'd like this to work, but it seems like it relies on packages being statically "good" or "bad" - what happens if a package is legitimately well trusted but then the main dev gets backdoored and a bit of extra code is injected?
  - rndhouse 5y ago
    That extra code will stand out as not having been reviewed.
    - yjftsjthsd-h 5y ago
      Oh, you mean to have reviewers look at every line of every version (at least cumulatively). Yes, that would work, and while the effort is significant I appreciate that it's the effort you'd want regardless so this helps share the load.
madjam002 5y ago
This is like the third one this week right? I know people keep saying about post-install should be opt out but then malware will just wait for first run instead. How about an option to refuse to install any packages that have been published in the past week/2 weeks? That way hopefully malware like this would have been spotted before you end up running it locally.
- ant6n 5y ago
  If everybody waits two weeks, then nobody will notice it on the first two weeks.
  - dane-pgp 5y ago
    The registry could send an email to the account which uploaded the package saying "Thank you for uploading version 1.2.3 of your-package." which would give them two weeks to think "Wait, I didn't upload a new version." Of course, if the attacker has access to their npm account, they can probably change the email address associated with the account too, so change-of-email requests should send a "Thank you for changing your email address" to the original address. The developer might have difficulty regaining control of the account, but hopefully they could inform the npm security team who could quite quickly confirm that a malicious package had been uploaded, which would be enough to get the malicious package taken down and the account locked.
- m4rtink 5y ago
  They could also attack metadata parsers next - I don't think those are very hardened right now.
ricardobayes 5y ago
Seems like a good choice to work at a cybersecurity company these days. Job security is guaranteed.
- drdaeman 5y ago
  Yea, but you'll end up cursing everything about computing because everyone and their dog starts their day with another `curl | sudo bash` pipe that installs something all across the system pulling in a metric shitton of random packages and you can't even imagine why all this nonsense is needed for a hello world app.
binarynate 5y ago
This is why JS runtimes should add the ability to set permissions on a per-module basis. Deno is a step in the right direction by requiring permissions for a script to be specified (e.g. deno run --allow-read --allow-net myscript.ts), but the permissions are global for the entire script and can't (yet?) be configured differently for each module / dependency.
- cxr 5y ago
  Alternatively, JS programmers should exhibit less contempt for the standardized, sandboxed runtime that JS was originally created to target: the Web browser. What's nuts is that any of these projects (whether they be single components, larger utilities, or full-blown apps) require a build step that involves anything more complicated[1] than a single machine-readable document in the web browser's native file format and that sits alongside (or in place of[2]) the project README. With so many programmers writing code for the express purpose of making digital documents with behavior dynamic enough to trick you into thinking that the page you have open is really an app, no one in the community with any clout ever stops and says, "Gee, since we're at it, maybe we ought to take this tech that enables us to securely run code on demand and focus it on the goal of allowing other programmers to configure all these modules that we're sharing with one another, or to handle the finishing step of a collection of modules that make up a given app." Then again, that would presume that any of the stuff that this industry engages in is actually meant to solve any problem, rather than creating a neverending supply of them in order to justify the paychecks being written and the egos they're feeding. If stuff's not laughably overengineered to the point of constantly breaking for no good reason[3], does it even count as "real"[4] programming? 1. https://www.colbyrussell.com/2019/03/06/how-to-displace-javascript.html https://www.colbyrussell.com/2019/03/06/how-to-displace-java... 2. https://news.ycombinator.com/item?id=28407936 https://news.ycombinator.com/item?id=28407936 3. https://news.ycombinator.com/item?id=24494434 https://news.ycombinator.com/item?id=24494434 4. https://news.ycombinator.com/item?id=17165784 https://news.ycombinator.com/item?id=17165784
  - binarynate 5y ago
    JS programmers don't have contempt for browsers, it's just that server runtimes like Node and Deno serve a different purpose. A browser isn't the right tool for running a server application or a command line program. If you want a server runtime that behaves more like a browser, though, check out Deno.
bluefox 5y ago
Is the advisory genuine? It links to the github repo, where the latest commit is from 2018 for version 1.2.8. It links to npmjs page, that shows 48 versions, where the latest version is 1.2.8 from "3 years ago". Yet it has 1.2.9/1.3.9/2.3.9 for "Affected versions". Did npmjs "revert" these versions and any clue of their existence? The npmjs page links to dominictarr's repository. The npmjs site doesn't seem to have a "who owns this package name" besides the repository/homepage links. Very confusing. I remember some years ago there was some story involving the original author's handing maintainership rights to some shady dude. Is it about that time, or is it about something more current?
- speeder 5y ago
  I saw in one of the repos the maintainer confused about what happened, seemly someone somehow impersonated him and released new versions to npm without actually touching the repo itself!
  - deleted 5y ago
    [deleted]
- jiggawatts 5y ago
  Practically all package managers (NuGet, crates.io, NPM, etc...) are decoupled from the source code. What you download is NOT necessarily what's in GitHub. I pointed this flaw out repeatedly in the Rust forums when there were discussions related to improvements that could be to crates.io. They made it very clear that "everyone understands" that crates themselves are the "source of truth", and that nobody should be doing security reviews by going to GitHub or wherever. So what happens in reality? Precisely what you just did. People instinctively click the source repo link, and browse around in the GitHub history view to "see what happened". Sigh. It's like trying to explain to someone that the cargo lift design of the Death Star is dangerous without handrails. Then someone points out that when you signed up to be a Stormtrooper on the Death Star there was a clause in the contract (page 537 paragraph 7) that clearly states that it is your responsibility to avoid fatal falls due to precipitous ledges.
  - 5y ago
joshuanapoli 5y ago
How long were the compromised packages available from npm?
armchairhacker 5y ago
Genuinely curious: why is malware always discovered in npm packages, and not pip (python), gradle/maven (JVM), cabal (Haskell), cargo (Rust), CRAN (R), etc.? Or are there major vulnerable packages in those repos but they just don't get audited?
- swiley 5y ago
  I thought someone happened in pip the other year. Part of the NPM issue is that everything gets atomized into tiny libraries and no one seems to care about the dependency explosion.
- Angius 5y ago
  It's an attractive target. Other ecosystems (maybe besides Rust) rely on large packages with minimal dependencies, and those packages are often first-party (Entity Framework, for example). NPM meanwhile is a neverending net of tiny oneliner packages, required by other oneliner packages, required by twoliner packages, required by single-function packages, required by... required by React. And thus, adding malware to `is-number` adds it to all 8766235452 packages that depend on it.
- tommek4077 5y ago
  The older such a system is, the more there is a "don't trust anyone" mentality. Some decades in the past you did not just run alien code in your system. Edit: without looking at it beforehand
- moreati 5y ago
  It isn't always just in NPM, although NPM might be more targetted and/or more publicised. There have been cases in PyPI (e.g. https://labs.sogeti.com/analysis-of-the-biggest-python-supply-chain-attack-ever/ https://labs.sogeti.com/analysis-of-the-biggest-python-suppl..., https://thehackernews.com/2021/08/pypi-python-package-repository-patches.html https://thehackernews.com/2021/08/pypi-python-package-reposi...), and probably others too, but PyPI is the one I care about.
- schleck8 5y ago
  There definitely is malware around on PyPI, and typosquatting.
cookiengineer 5y ago
Every time I see news like this, I am amazed by the absolute lack of permission management in nodejs and npm. I mean, a package.json with changing permissions and an alert or manual confirmation step could've easily fixed this. NPM is pretty much the definition of a security nightmare, because you cannot guarantee anything. Any dependency down the tree can compromise anything upstream. I think that package managers must offer build bots that use the source codes (git repositories) as sources of truth rather than their own packages. That's the only way that comes to mind to guarantee that the publisher of the package is actually the same owner. If a git repo changes, warn all users. If a permission changes, warn all users. If a header/symbol file changes, warn all users.
sva_ 5y ago
Actually had this package installed somewhere... "version": "1.2.8", Pfew, really lucky. Going to nuke npm now.
greggman3 5y ago
Would it be better for package managers to default to staying at a fixed version? I know npm defaults to semver upgrades. You say npm install foo@3.1.7 And it, by default, inserts "foo@^3.1.7" which means "anything 3.1.7 or higher but not "4.x.x". In other words, the next time someone installs the dependencies it could be 3.1.8, 3.9.7, 3.1234.999 etc... But maybe it should default to just the actual version and all upgrades should be required to be manual. Checking my HD I see I have lots of references to "rc@^1.1.6", "rc@^1.2.8" etc, all of which would install 1.2.9 if reinstall the deps

140 points by hjek 5y ago

hjek 5y ago

More info: https://therecord.media/malware-found-in-coa-and-rc-two-npm-packages-with-23m-weekly-downloads/ https://therecord.media/malware-found-in-coa-and-rc-two-npm-...

bluefox 5y ago
Thanks. > Since then, the npm security team has removed all the compromised coa and rc versions to prevent developers from accidentally infecting themselves. Removing all trace of evidence is not something "security teams" should do. Instead of sweeping security incidents under the rug (where twitterverse resides), they should at least mention the existence of these versions and that they contain malware on the package page.
- bqkJoKocJz9jz 5y ago
  They posted the [version diffs] (https://my.diffend.io/npm/coa/2.0.2/2.0.4)in https://my.diffend.io/npm/coa/2.0.2/2.0.4)in the article. Not sure if this site catches all the changes though.

greenyoda 5y ago

See also the ongoing discussion about malware in "Coa", another NPM package: https://news.ycombinator.com/item?id=29116878 https://news.ycombinator.com/item?id=29116878

dang 5y ago
Also recent: NPM package ‘ua-parser-JS’ with more than 7M weekly download is compromised - https://news.ycombinator.com/item?id=28962168 https://news.ycombinator.com/item?id=28962168 - Oct 2021 (141 comments)

schleck8 5y ago

And 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 component to be this easily abused. One of the highlights is when someone recently used NPM to spread ransomware via a fake Roblox API package.[3] [1] https://www.virustotal.com/gui/file/26451f7f6fe297adf6738295b1dcc70f7678434ef21d8b6aad5ec00beb8a72cf/detection https://www.virustotal.com/gui/file/26451f7f6fe297adf6738295... [2] https://github.com/kevoreilly/CAPEv2 https://github.com/kevoreilly/CAPEv2 [3] https://www.reddit.com/r/programming/comments/qgz0em/fake_npm_roblox_api_package_installs_ransomware/ https://www.reddit.com/r/programming/comments/qgz0em/fake_np...

iancarroll 5y ago
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.
- schleck8 5y ago
  I think Chocolatey has manual screens when there are more than 5 detections, but not entirely sure
- schemescape 5y ago
  Given that these attacks are becoming increasingly common, package registries could at least install each package (prior to publishing) in some isolated container or VM and then run some similar malware detection on the resulting file system. Honestly, I'm strongly considering moving away from the NPM ecosystem because it's clearly become a target for malware.
  - 5y ago

qwerty2021 5y ago

I 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?

afavour 5y ago
Command line argument parsing and config loading both seem like very sensible library abstractions to me. This isn’t leftpad.
- havkd 5y ago
  Command line argument parsing and config loading both seem like something that the standard library should provide.
  - megumax 5y ago
    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. [1] https://github.com/spf13/cobra https://github.com/spf13/cobra
    - MrStonedOne 5y ago
      php
    - kitsunesoba 5y ago
      It's not part of the standard library, but Swift has the first-party ArgumentParser[0]. Other languages could use a similar model (though what "first party" means for JavaScript is unclear). [0]: https://github.com/apple/swift-argument-parser https://github.com/apple/swift-argument-parser

tolmasky 5y ago

If you're interested in preventing this sort of thing, I'd appreciate comments on this [RFC](https://github.com/npm/rfcs/pull/488 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 packages in question, not even running any code in the package, the malicious program has a chance at running. RFC: https://github.com/npm/rfcs/pull/488 https://github.com/npm/rfcs/pull/488 Related HN post: https://news.ycombinator.com/item?id=29122473 https://news.ycombinator.com/item?id=29122473

chakkepolja 5y ago
Problem is, as someone mentioned in the GitHub thread as well, people just press OK, especially if it's a transitive dependency.
- Me1000 5y ago
  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.
- tolmasky 5y ago
  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.

BonoboIO 5y ago

Using npm is like russian roulette. Someday it makes your head hurt really bad!

hn_throwaway_99 5y ago

One of the thing I wish was really much easier to do with NPM is, when running `npm update`, to only pick up the most recent compatible versions from X days ago. That is, for sensitive apps, I don't want to use versions that are less than, say, a month or so old unless I specifically override it. I want to stay up-to-date but not too bleeding edge, specifically to avoid situations like this.

dane-pgp 5y ago
That would be a big improvement, but I assume that people would override this check whenever they were updating a package to fix a minor accidental vulnerability that had been found in it (detected by an "npm audit"). An attacker who had control over an account would wait until just such a moment to add their own version which includes a much worse payload, and people would rush to download it, thinking they were just installing a fix for the minor vulnerability.
beart 5y ago
renovate bot can do this. set it to wait for x days before accepting a merge, and pin your versions so there's no chance to update by mistake.

rndhouse 5y ago

I've created Vouch in an attempt to address this problem: https://github.com/vouch-dev/vouch https://github.com/vouch-dev/vouch Vouch lets users create and share reviews for NPM packages. Project dependencies can then be checked against those reviews. Vouch uses extensions to interface with package ecosystems. It's simple to create a new extension. Extensions currently exist for NPM, PyPi, and Ansible Galaxy. I'm currently working on a website to index known reviews and publish official reviews. I hope you guys find it useful! Drop by the Matrix channel if you have any feedback to share: #vouch:matrix.org

hjek 5y ago
Sounds really interesting. I'm kinda scared to use npm right now to be honest. What dangers may be hidden deep in the dependency trees? But is a review of every update then done, because rc used to be a legit package?
- rndhouse 5y ago
  A review corresponds to a particular version number. But the review process does not need to start from scratch with each version number increment. Reviews from previous versions can be leveraged to lessen the workload.
yjftsjthsd-h 5y ago
I'd like this to work, but it seems like it relies on packages being statically "good" or "bad" - what happens if a package is legitimately well trusted but then the main dev gets backdoored and a bit of extra code is injected?
- rndhouse 5y ago
  That extra code will stand out as not having been reviewed.
  - yjftsjthsd-h 5y ago
    Oh, you mean to have reviewers look at every line of every version (at least cumulatively). Yes, that would work, and while the effort is significant I appreciate that it's the effort you'd want regardless so this helps share the load.

madjam002 5y ago

This is like the third one this week right? I know people keep saying about post-install should be opt out but then malware will just wait for first run instead. How about an option to refuse to install any packages that have been published in the past week/2 weeks? That way hopefully malware like this would have been spotted before you end up running it locally.

ant6n 5y ago
If everybody waits two weeks, then nobody will notice it on the first two weeks.
- dane-pgp 5y ago
  The registry could send an email to the account which uploaded the package saying "Thank you for uploading version 1.2.3 of your-package." which would give them two weeks to think "Wait, I didn't upload a new version." Of course, if the attacker has access to their npm account, they can probably change the email address associated with the account too, so change-of-email requests should send a "Thank you for changing your email address" to the original address. The developer might have difficulty regaining control of the account, but hopefully they could inform the npm security team who could quite quickly confirm that a malicious package had been uploaded, which would be enough to get the malicious package taken down and the account locked.
m4rtink 5y ago
They could also attack metadata parsers next - I don't think those are very hardened right now.

ricardobayes 5y ago

Seems like a good choice to work at a cybersecurity company these days. Job security is guaranteed.

drdaeman 5y ago
Yea, but you'll end up cursing everything about computing because everyone and their dog starts their day with another `curl | sudo bash` pipe that installs something all across the system pulling in a metric shitton of random packages and you can't even imagine why all this nonsense is needed for a hello world app.

binarynate 5y ago

This is why JS runtimes should add the ability to set permissions on a per-module basis. Deno is a step in the right direction by requiring permissions for a script to be specified (e.g. deno run --allow-read --allow-net myscript.ts), but the permissions are global for the entire script and can't (yet?) be configured differently for each module / dependency.

cxr 5y ago
Alternatively, JS programmers should exhibit less contempt for the standardized, sandboxed runtime that JS was originally created to target: the Web browser. What's nuts is that any of these projects (whether they be single components, larger utilities, or full-blown apps) require a build step that involves anything more complicated[1] than a single machine-readable document in the web browser's native file format and that sits alongside (or in place of[2]) the project README. With so many programmers writing code for the express purpose of making digital documents with behavior dynamic enough to trick you into thinking that the page you have open is really an app, no one in the community with any clout ever stops and says, "Gee, since we're at it, maybe we ought to take this tech that enables us to securely run code on demand and focus it on the goal of allowing other programmers to configure all these modules that we're sharing with one another, or to handle the finishing step of a collection of modules that make up a given app." Then again, that would presume that any of the stuff that this industry engages in is actually meant to solve any problem, rather than creating a neverending supply of them in order to justify the paychecks being written and the egos they're feeding. If stuff's not laughably overengineered to the point of constantly breaking for no good reason[3], does it even count as "real"[4] programming? 1. https://www.colbyrussell.com/2019/03/06/how-to-displace-javascript.html https://www.colbyrussell.com/2019/03/06/how-to-displace-java... 2. https://news.ycombinator.com/item?id=28407936 https://news.ycombinator.com/item?id=28407936 3. https://news.ycombinator.com/item?id=24494434 https://news.ycombinator.com/item?id=24494434 4. https://news.ycombinator.com/item?id=17165784 https://news.ycombinator.com/item?id=17165784
- binarynate 5y ago
  JS programmers don't have contempt for browsers, it's just that server runtimes like Node and Deno serve a different purpose. A browser isn't the right tool for running a server application or a command line program. If you want a server runtime that behaves more like a browser, though, check out Deno.

bluefox 5y ago

Is the advisory genuine? It links to the github repo, where the latest commit is from 2018 for version 1.2.8. It links to npmjs page, that shows 48 versions, where the latest version is 1.2.8 from "3 years ago". Yet it has 1.2.9/1.3.9/2.3.9 for "Affected versions". Did npmjs "revert" these versions and any clue of their existence? The npmjs page links to dominictarr's repository. The npmjs site doesn't seem to have a "who owns this package name" besides the repository/homepage links. Very confusing. I remember some years ago there was some story involving the original author's handing maintainership rights to some shady dude. Is it about that time, or is it about something more current?

speeder 5y ago
I saw in one of the repos the maintainer confused about what happened, seemly someone somehow impersonated him and released new versions to npm without actually touching the repo itself!
- deleted 5y ago
  [deleted]
jiggawatts 5y ago
Practically all package managers (NuGet, crates.io, NPM, etc...) are decoupled from the source code. What you download is NOT necessarily what's in GitHub. I pointed this flaw out repeatedly in the Rust forums when there were discussions related to improvements that could be to crates.io. They made it very clear that "everyone understands" that crates themselves are the "source of truth", and that nobody should be doing security reviews by going to GitHub or wherever. So what happens in reality? Precisely what you just did. People instinctively click the source repo link, and browse around in the GitHub history view to "see what happened". Sigh. It's like trying to explain to someone that the cargo lift design of the Death Star is dangerous without handrails. Then someone points out that when you signed up to be a Stormtrooper on the Death Star there was a clause in the contract (page 537 paragraph 7) that clearly states that it is your responsibility to avoid fatal falls due to precipitous ledges.
- 5y ago

joshuanapoli 5y ago

How long were the compromised packages available from npm?

armchairhacker 5y ago

Genuinely curious: why is malware always discovered in npm packages, and not pip (python), gradle/maven (JVM), cabal (Haskell), cargo (Rust), CRAN (R), etc.? Or are there major vulnerable packages in those repos but they just don't get audited?

swiley 5y ago
I thought someone happened in pip the other year. Part of the NPM issue is that everything gets atomized into tiny libraries and no one seems to care about the dependency explosion.
Angius 5y ago
It's an attractive target. Other ecosystems (maybe besides Rust) rely on large packages with minimal dependencies, and those packages are often first-party (Entity Framework, for example). NPM meanwhile is a neverending net of tiny oneliner packages, required by other oneliner packages, required by twoliner packages, required by single-function packages, required by... required by React. And thus, adding malware to `is-number` adds it to all 8766235452 packages that depend on it.
tommek4077 5y ago
The older such a system is, the more there is a "don't trust anyone" mentality. Some decades in the past you did not just run alien code in your system. Edit: without looking at it beforehand
moreati 5y ago
It isn't always just in NPM, although NPM might be more targetted and/or more publicised. There have been cases in PyPI (e.g. https://labs.sogeti.com/analysis-of-the-biggest-python-supply-chain-attack-ever/ https://labs.sogeti.com/analysis-of-the-biggest-python-suppl..., https://thehackernews.com/2021/08/pypi-python-package-repository-patches.html https://thehackernews.com/2021/08/pypi-python-package-reposi...), and probably others too, but PyPI is the one I care about.
schleck8 5y ago
There definitely is malware around on PyPI, and typosquatting.

cookiengineer 5y ago

Every time I see news like this, I am amazed by the absolute lack of permission management in nodejs and npm. I mean, a package.json with changing permissions and an alert or manual confirmation step could've easily fixed this. NPM is pretty much the definition of a security nightmare, because you cannot guarantee anything. Any dependency down the tree can compromise anything upstream. I think that package managers must offer build bots that use the source codes (git repositories) as sources of truth rather than their own packages. That's the only way that comes to mind to guarantee that the publisher of the package is actually the same owner. If a git repo changes, warn all users. If a permission changes, warn all users. If a header/symbol file changes, warn all users.

sva_ 5y ago

Actually had this package installed somewhere... "version": "1.2.8", Pfew, really lucky. Going to nuke npm now.

greggman3 5y ago

Would it be better for package managers to default to staying at a fixed version? I know npm defaults to semver upgrades. You say npm install foo@3.1.7 And it, by default, inserts "foo@^3.1.7" which means "anything 3.1.7 or higher but not "4.x.x". In other words, the next time someone installs the dependencies it could be 3.1.8, 3.9.7, 3.1234.999 etc... But maybe it should default to just the actual version and all upgrades should be required to be manual. Checking my HD I see I have lots of references to "rc@^1.1.6", "rc@^1.2.8" etc, all of which would install 1.2.9 if reinstall the deps