16 ms·

Friendly reminder, every time this happens... https://github.com/npm/npm/pull/4016 https://github.com/npm/npm/pull/4016 "However, this is just a piece of an o

by danjoc 9y ago

Friendly reminder, every time this happens... https://github.com/npm/npm/pull/4016 https://github.com/npm/npm/pull/4016 "However, this is just a piece of an overall solution, and it brings with it a lot of the baggage that comes along whenever GnuPG or PGP get involved. Without a web of trust (sigh), a PKI (ugh), or some other mechanism to tie identities to trust metrics, this is essentially a complicated, very expensive, and fragile version of the shasum check npm already has." I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist. They've done literally nothing. https://github.com/node-forward/discussions/issues/29 https://github.com/node-forward/discussions/issues/29 Last discussion was > 1 year ago. They simply do not care. Security isn't even an afterthought.

stu_k 9y ago
I'm confused, how would the above help with a typosquatting package? The issue here is that `crossenv` is malicious, and `cross-env` isn't. The signatures would all be ok in both cases.
- KirinDave 9y ago
  It wouldn't. People look for any opportunity they can muster to browbeat the node community. Probably because they're jealous of its outsized success.
- danjoc 9y ago
  The signature might validate, but at the point you go to Kent C Dobbs to verify he controls the key, the ruse is uncovered.
  - koolba 9y ago
    And nobody but the most tinfoily of us is going to do that. So short of a web of trust or delegation, you get nothing more than a checksum.
    - danjoc 9y ago
      >nobody but the most tinfoily of us is going to do that Are you characterizing people who verify keys as crazy? It's not like you can't just reach out to @kentcdodds and get an answer in under 5 hours as Oscar Blomsten just did in the OP.
      - pfooti 9y ago
        I'm working on a node-based REST endpoint. It's nothing special - it looks up stuff in the database, does CRUD things, pokes postgres, has a cache layer in redis, a websocket for handling sidechannel stuff like model update events for realtime data updates and so on. It has 514 dependencies in total. It's actually only 39 real dependencies, the rest are subs and sub-subs (after removing duplicates). Also, some of those 39 dependencies are things I wrote (various general-purpose ORM type mappers for different styles of datastore), so I guess that number could be a bit lower. Either way, there is a lot of verification to do here. And there's two different kinds of attacks. The dangerous attack that automated key lookups and signing can protect against would be someone publishing a malicious version n+1 of a library I wrote or rely on (either hacking the npm credentials or just buying access as in the case of the minimap / autocomplete-python debacle from last week). In that case, the key change might be noted, but then again, people lose access to keys so you'd want to have ways for package authors to revoke and reissue keys (in which case compromised or purchased credentials might not be noted). Another type of attack is the one we're seeing here - a typo attack. Without protections of the type discussed in maybekatz's tweet (in that thread), it's pretty hard to see you're in a typo attack. The malicious publisher can still sign a malicious package, and if you accidentally install crossenv instead of cross-env, there's no protection from signing. Again, unless you are manually auditing all 500+ dependencies in your tree by figuring out who the author should be, since you're viewing the npm-reported information as potentially compromised you'll need to find other connections to that person. At this point, you've basically recreated a web-of-trust architecture, with all the challenges that go with it. This isn't simple, I don't think isaacs and the rest of the npm crew are maliciously ignoring obvious answers. It's more likely that the actual answers are hard to find and harder to scale. The answer ultimately is: we need to audit all the code we use, or have someone else we trust audit the code we use. And if we're not auditing it ourselves, we probably have to pay someone else to do that, and that's not cheap. Walled gardens have their benefits, but explosive growth and rapid invention / iteration / elaboration is not one of them.
  - jonknee 9y ago
    If you don't know the correct package name in the first place, nothing in package.json can be used to validate.
  - Ajedi32 9y ago
    What ruse? "Kent C Dobbs" published the `cross-env` package, not the `crossenv` package. In this case, the attacker is the legitimate owner of the `crossenv` package; the problem is that's not the package I actually want. If I had typed `npm install cross-env` instead of `npm install crossenv`, I would have gotten a non-malicious, perfectly legitimate copy of the package I wanted; no GPG key required.
  - PeterisP 9y ago
    Why would anyone go to Kent C Dobbs to verify that he controls the key instead of going to Joe R Badguy or whoever is listed as the author of the malicious package? There's no secure list of "good people" and there's no secure list that provides a mapping of who should be signing each package. Especially for things maintained by multiple people, I wouldn't have (and shouldn't have to have) any idea of which particular people are the proper signers.
- ris 9y ago
  It wouldn't. Nothing will help with package managers that follow the "wild west" or "any old crap" model where there is no maintainer or distributor between the developer and consumer that is allowed to perform any sort of quality control or sanitisation. This is what makes me hugely favour the "maintained" model followed by distributions or nix/guix. The wild west model scares the bejesus out of me to be honest.
  - krapp 9y ago
    The "wild west" model doesn't disallow anyone from providing quality control, it just doesn't enforce one particular person or entity's idea of what quality control should be.
    - ris 9y ago
      I think we disagree with definitions of "quality control". My definition goes hand in hand with consistency.
iamakulov 9y ago
npm is working on a solution for misspellings through: https://twitter.com/maybekatz/status/892501201551368192 https://twitter.com/maybekatz/status/892501201551368192
- jnbiche 9y ago
  They should first get package signatures implemented, it's a bigger threat to the npm community. At worst, the mispelled packages effect a handful of people who don't double check the package name for the package they're installing. If someone compromises the integrity of an ultra popular package, it threatens thousands, perhaps even millions of people (counting all people consuming the code downstream, ie users). And the npm repo has been shown to be vulnerable to compromise multiple times over the past few years. Here's a writeup of just some of the more egregious security weaknesses of NPM packages in recent history: https://www.bleepingcomputer.com/news/security/52-percent-of-all-javascript-npm-packages-could-have-been-hacked-via-weak-credentials/ https://www.bleepingcomputer.com/news/security/52-percent-of...
  - tomjakubowski 9y ago
    Requiring 2FA on publish would do just as well to prevent malicious actors from exploiting poor user passwords, and without imposing such a burden on developers. I don't have numbers, but it certainly seems like developers are more likely to maintain a set of TOTP key/epoch pairs than a PGP keypair. I guess that TOTP-based 2FA challenges would be annoying in the case where CI performs the "publish" step.
    - cyphar 9y ago
      The problem is that users downloading the package can't verify that the developer used TOTP to publish. Really, it takes minimal effort to make and use a GPG key. You can write a fairly basic script to automate the signing of stuff as well. Here's an example (it even signs the source archive): https://github.com/openSUSE/umoci/blob/master/hack/release.sh https://github.com/openSUSE/umoci/blob/master/hack/release.s...
KirinDave 9y ago
> I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist. But they're right. What exactly would PKI do here? Someone is generating confusion. You could argue that maybe a PKI solution could be used to inform the UI such that users are less likely to make mistakes, but browbeating NPM over this is silly. Maven has this problem (people really concerned built their own tools: https://github.com/whispersystems/gradle-witness https://github.com/whispersystems/gradle-witness), choclatey has this problem, pip has this problem, everyone has this problem. The big difference is that the NPM ecosystem is just an order of magnitude bigger than most others, and its model of many small packages can hide many more key packages in the noise.
- danjoc 9y ago
  >Maven has this problem What malicious packages have been found on Maven central?
  - KirinDave 9y ago
    Why don't you google or follow the link I already gave?
    - danjoc 9y ago
      Exactly what I thought. You can't name one. Coincidentally, Maven central requires GPG signatures.
      - KirinDave 9y ago
        As we all know you can only sign a piece of code if it is free of malicious software. Heck, I read that you can't even make a GPG key without proving your virtue to Richard Stallman in festivus-style competition.
- slackingoff2017 9y ago
  Maven does not have this problem. That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. My packages are all cryptographically signed with my private key. Maven doesn't just offer code signing, it's mandatory to deploy projects to the central repo. The automated package verifier will reject you if you don't have it. If someone gains access to my account and tries to modify my package without my private key it will not be accepted into the repo. And actually, I'm pretty sure maven signs not just the code but also the documentation and everything else within your package. Light-years ahead of NPM, even after their publicized issues.
skywhopper 9y ago
I agree that npm et al should support code signing but genuine question: how would package signing solve this particular issue? This was not a code integrity attack. Presumably the author of the malicious package can sign his code as well. I suspect if the malicious author had made the package proxy the desired package's exports it would have been a lot longer before this was noticed if it ever was.
- derefr 9y ago
  The usual way code-signing is used here is that code for a platform is signed with keys issued by the platform manager acting as a CA, who does identity verification at time of issuance. Thus, if the platform-as-CA revokes someone's code-signing cert, they're effectively banning that person (rather than just that pseudonymous identity) from ever publishing on their platform again. It not only works after-the-fact, but is usually also quite effective as a deterrent to stop people from publishing malware in the first place (except state-level actors who can afford to create and burn real identities for the sake of cyberwar.)
arca_vorago 9y ago
I think this is a problem with the "fad" approach to dev. As a sysadmin I try to stay on top of tech at a 50k ft view, so when node and angular and MEAN stack started showing up everywhere, I tried my hand a bit, and walked away remembering how much I hated the javascript ecosystem that existed before these things, and how the community seemed to be younger, newer devs trying something shiny and repeating fuckups that had already been through other langs/environments. Security for these kinds of devs is not even an afterthought, it's someone elses problem.
tuananh 9y ago
@danjoc: do you have a reference for this? I'm interested. > I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist.
ubernostrum 9y ago
Signed packages tell you one and only one thing: that the package was signed by a particular key. They don't tell you that the package was signed by someone you think should be authorized to produce that package. Linux distros can get away with signing everything because there's typically a very small set of people the distro's organizational structure trusts to make packages, and thus a very small set of keys and real-world identities to verify. Open-to-the-public package systems cannot hope to verify the identity of every person who creates a package, and thus cannot provide you with the web-of-trust model you want (since what you seem to want is not "is this signed by a PGP key" but rather "is this signed by a PGP key I personally think should be authorized to make packages").
dylan-m 9y ago
Better verification is well-meaning and all, but it ignores the central problem of NPM-land: there are just way too many tiny little one-off packages for any human being to possibly verify, even with the right tools. And whenever you happen to include something non-trivial you're basically trusting that somebody else has done just that with all of their dependencies, and so on and so forth until you have 600 different packages nobody knows anything about in your node_modules directory. It's almost as if most of NPM should be replaced by some kind of ... self-contained encyclopedia of code. Maybe it could even be maintained by a single group of people that get along with each other and adhere to a release schedule. And perhaps there is some way it could be organized into modules with consistent documentation. While we're talking about this amazing world of tomorrow: maybe those docs could even be on the cloud, with hyperlinks between sections! Okay, sorry, getting ahead of myself. It's crazy-talk, I know.
jondubois 9y ago
They said that they do a shasum check so obviously they do care about security and have it under control. npm is hands down the best package manager I've used and they actually do improve with every version.
- ris 9y ago
  > npm is hands down the best package manager I've used You poor poor bastard
jwilk 9y ago
> insults two legends in crypto Who?

by danjoc 9y ago

stu_k 9y ago

I'm confused, how would the above help with a typosquatting package? The issue here is that `crossenv` is malicious, and `cross-env` isn't. The signatures would all be ok in both cases.

KirinDave 9y ago
It wouldn't. People look for any opportunity they can muster to browbeat the node community. Probably because they're jealous of its outsized success.
danjoc 9y ago
The signature might validate, but at the point you go to Kent C Dobbs to verify he controls the key, the ruse is uncovered.
- koolba 9y ago
  And nobody but the most tinfoily of us is going to do that. So short of a web of trust or delegation, you get nothing more than a checksum.
  - danjoc 9y ago
    >nobody but the most tinfoily of us is going to do that Are you characterizing people who verify keys as crazy? It's not like you can't just reach out to @kentcdodds and get an answer in under 5 hours as Oscar Blomsten just did in the OP.
    - pfooti 9y ago
      I'm working on a node-based REST endpoint. It's nothing special - it looks up stuff in the database, does CRUD things, pokes postgres, has a cache layer in redis, a websocket for handling sidechannel stuff like model update events for realtime data updates and so on. It has 514 dependencies in total. It's actually only 39 real dependencies, the rest are subs and sub-subs (after removing duplicates). Also, some of those 39 dependencies are things I wrote (various general-purpose ORM type mappers for different styles of datastore), so I guess that number could be a bit lower. Either way, there is a lot of verification to do here. And there's two different kinds of attacks. The dangerous attack that automated key lookups and signing can protect against would be someone publishing a malicious version n+1 of a library I wrote or rely on (either hacking the npm credentials or just buying access as in the case of the minimap / autocomplete-python debacle from last week). In that case, the key change might be noted, but then again, people lose access to keys so you'd want to have ways for package authors to revoke and reissue keys (in which case compromised or purchased credentials might not be noted). Another type of attack is the one we're seeing here - a typo attack. Without protections of the type discussed in maybekatz's tweet (in that thread), it's pretty hard to see you're in a typo attack. The malicious publisher can still sign a malicious package, and if you accidentally install crossenv instead of cross-env, there's no protection from signing. Again, unless you are manually auditing all 500+ dependencies in your tree by figuring out who the author should be, since you're viewing the npm-reported information as potentially compromised you'll need to find other connections to that person. At this point, you've basically recreated a web-of-trust architecture, with all the challenges that go with it. This isn't simple, I don't think isaacs and the rest of the npm crew are maliciously ignoring obvious answers. It's more likely that the actual answers are hard to find and harder to scale. The answer ultimately is: we need to audit all the code we use, or have someone else we trust audit the code we use. And if we're not auditing it ourselves, we probably have to pay someone else to do that, and that's not cheap. Walled gardens have their benefits, but explosive growth and rapid invention / iteration / elaboration is not one of them.
- jonknee 9y ago
  If you don't know the correct package name in the first place, nothing in package.json can be used to validate.
- Ajedi32 9y ago
  What ruse? "Kent C Dobbs" published the `cross-env` package, not the `crossenv` package. In this case, the attacker is the legitimate owner of the `crossenv` package; the problem is that's not the package I actually want. If I had typed `npm install cross-env` instead of `npm install crossenv`, I would have gotten a non-malicious, perfectly legitimate copy of the package I wanted; no GPG key required.
- PeterisP 9y ago
  Why would anyone go to Kent C Dobbs to verify that he controls the key instead of going to Joe R Badguy or whoever is listed as the author of the malicious package? There's no secure list of "good people" and there's no secure list that provides a mapping of who should be signing each package. Especially for things maintained by multiple people, I wouldn't have (and shouldn't have to have) any idea of which particular people are the proper signers.
ris 9y ago
It wouldn't. Nothing will help with package managers that follow the "wild west" or "any old crap" model where there is no maintainer or distributor between the developer and consumer that is allowed to perform any sort of quality control or sanitisation. This is what makes me hugely favour the "maintained" model followed by distributions or nix/guix. The wild west model scares the bejesus out of me to be honest.
- krapp 9y ago
  The "wild west" model doesn't disallow anyone from providing quality control, it just doesn't enforce one particular person or entity's idea of what quality control should be.
  - ris 9y ago
    I think we disagree with definitions of "quality control". My definition goes hand in hand with consistency.

iamakulov 9y ago

npm is working on a solution for misspellings through: https://twitter.com/maybekatz/status/892501201551368192 https://twitter.com/maybekatz/status/892501201551368192

jnbiche 9y ago
They should first get package signatures implemented, it's a bigger threat to the npm community. At worst, the mispelled packages effect a handful of people who don't double check the package name for the package they're installing. If someone compromises the integrity of an ultra popular package, it threatens thousands, perhaps even millions of people (counting all people consuming the code downstream, ie users). And the npm repo has been shown to be vulnerable to compromise multiple times over the past few years. Here's a writeup of just some of the more egregious security weaknesses of NPM packages in recent history: https://www.bleepingcomputer.com/news/security/52-percent-of-all-javascript-npm-packages-could-have-been-hacked-via-weak-credentials/ https://www.bleepingcomputer.com/news/security/52-percent-of...
- tomjakubowski 9y ago
  Requiring 2FA on publish would do just as well to prevent malicious actors from exploiting poor user passwords, and without imposing such a burden on developers. I don't have numbers, but it certainly seems like developers are more likely to maintain a set of TOTP key/epoch pairs than a PGP keypair. I guess that TOTP-based 2FA challenges would be annoying in the case where CI performs the "publish" step.
  - cyphar 9y ago
    The problem is that users downloading the package can't verify that the developer used TOTP to publish. Really, it takes minimal effort to make and use a GPG key. You can write a fairly basic script to automate the signing of stuff as well. Here's an example (it even signs the source archive): https://github.com/openSUSE/umoci/blob/master/hack/release.sh https://github.com/openSUSE/umoci/blob/master/hack/release.s...

KirinDave 9y ago

> I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist. But they're right. What exactly would PKI do here? Someone is generating confusion. You could argue that maybe a PKI solution could be used to inform the UI such that users are less likely to make mistakes, but browbeating NPM over this is silly. Maven has this problem (people really concerned built their own tools: https://github.com/whispersystems/gradle-witness https://github.com/whispersystems/gradle-witness), choclatey has this problem, pip has this problem, everyone has this problem. The big difference is that the NPM ecosystem is just an order of magnitude bigger than most others, and its model of many small packages can hide many more key packages in the noise.

danjoc 9y ago
>Maven has this problem What malicious packages have been found on Maven central?
- KirinDave 9y ago
  Why don't you google or follow the link I already gave?
  - danjoc 9y ago
    Exactly what I thought. You can't name one. Coincidentally, Maven central requires GPG signatures.
    - KirinDave 9y ago
      As we all know you can only sign a piece of code if it is free of malicious software. Heck, I read that you can't even make a GPG key without proving your virtue to Richard Stallman in festivus-style competition.
slackingoff2017 9y ago
Maven does not have this problem. That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. My packages are all cryptographically signed with my private key. Maven doesn't just offer code signing, it's mandatory to deploy projects to the central repo. The automated package verifier will reject you if you don't have it. If someone gains access to my account and tries to modify my package without my private key it will not be accepted into the repo. And actually, I'm pretty sure maven signs not just the code but also the documentation and everything else within your package. Light-years ahead of NPM, even after their publicized issues.

skywhopper 9y ago

I agree that npm et al should support code signing but genuine question: how would package signing solve this particular issue? This was not a code integrity attack. Presumably the author of the malicious package can sign his code as well. I suspect if the malicious author had made the package proxy the desired package's exports it would have been a lot longer before this was noticed if it ever was.

derefr 9y ago
The usual way code-signing is used here is that code for a platform is signed with keys issued by the platform manager acting as a CA, who does identity verification at time of issuance. Thus, if the platform-as-CA revokes someone's code-signing cert, they're effectively banning that person (rather than just that pseudonymous identity) from ever publishing on their platform again. It not only works after-the-fact, but is usually also quite effective as a deterrent to stop people from publishing malware in the first place (except state-level actors who can afford to create and burn real identities for the sake of cyberwar.)

arca_vorago 9y ago

I think this is a problem with the "fad" approach to dev. As a sysadmin I try to stay on top of tech at a 50k ft view, so when node and angular and MEAN stack started showing up everywhere, I tried my hand a bit, and walked away remembering how much I hated the javascript ecosystem that existed before these things, and how the community seemed to be younger, newer devs trying something shiny and repeating fuckups that had already been through other langs/environments. Security for these kinds of devs is not even an afterthought, it's someone elses problem.

tuananh 9y ago

@danjoc: do you have a reference for this? I'm interested. > I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist.

ubernostrum 9y ago

Signed packages tell you one and only one thing: that the package was signed by a particular key. They don't tell you that the package was signed by someone you think should be authorized to produce that package. Linux distros can get away with signing everything because there's typically a very small set of people the distro's organizational structure trusts to make packages, and thus a very small set of keys and real-world identities to verify. Open-to-the-public package systems cannot hope to verify the identity of every person who creates a package, and thus cannot provide you with the web-of-trust model you want (since what you seem to want is not "is this signed by a PGP key" but rather "is this signed by a PGP key I personally think should be authorized to make packages").

dylan-m 9y ago

Better verification is well-meaning and all, but it ignores the central problem of NPM-land: there are just way too many tiny little one-off packages for any human being to possibly verify, even with the right tools. And whenever you happen to include something non-trivial you're basically trusting that somebody else has done just that with all of their dependencies, and so on and so forth until you have 600 different packages nobody knows anything about in your node_modules directory. It's almost as if most of NPM should be replaced by some kind of ... self-contained encyclopedia of code. Maybe it could even be maintained by a single group of people that get along with each other and adhere to a release schedule. And perhaps there is some way it could be organized into modules with consistent documentation. While we're talking about this amazing world of tomorrow: maybe those docs could even be on the cloud, with hyperlinks between sections! Okay, sorry, getting ahead of myself. It's crazy-talk, I know.

jondubois 9y ago

They said that they do a shasum check so obviously they do care about security and have it under control. npm is hands down the best package manager I've used and they actually do improve with every version.

ris 9y ago
> npm is hands down the best package manager I've used You poor poor bastard

jwilk 9y ago

> insults two legends in crypto Who?