6 ms·

Similar problems exist in most package management systems. registries that have a manual review process mitigate this danger, but there's still always a risk of

Similar problems exist in most package management systems. registries that have a manual review process mitigate this danger, but there's still always a risk of malicious code getting into the world. Having said this, we'd like to make exploits such as those discussed in #319816 as difficult as possible. We're exploring supporting new authentication strategies: such as 2-factor authentication, SAML, and asymmetric key based authentication (some of these features are already available in our Enterprise product, but haven't made it to the public registry yet). npm's official response has more details on this subject: http://blog.npmjs.org/post/141702881055/package-install-scripts-vulnerability http://blog.npmjs.org/post/141702881055/package-install-scri...

raesene3 11y ago
Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware... Linux package managers are a different story of course.
- semi-extrinsic 11y ago
  Firefox has automated "malware checking" for extensions, the Mozilla AMO Validator, and it's been basically torn to pieces by the community for being not actually secure [1] plus a major hassle for developers [2], to the point that large extensions with hundreds of thousands of users have stopped using the official Firefox extensions repository. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1227867#c2 https://bugzilla.mozilla.org/show_bug.cgi?id=1227867#c2 [2] https://forums.zotero.org/discussion/28847/zotero-addon-is-no-longer-available-at-mozillas-addons/ https://forums.zotero.org/discussion/28847/zotero-addon-is-n...
  - raesene3 11y ago
    Yep it's a really nasty problem for any package manager that operates at scale. The problem is that without any centralized validation of packages, it leaves checking to each developer who uses the libraries and obviously from an effort standpoint that just makes it worse (i.e. if it's hard for the repo owner to do validation it's hard x number_of_users for it to be done by end users)
    - semi-extrinsic 11y ago
      The problem is basically how the centralized validation is supposed to work. For e.g. the Linux kernel, it's doable because all code in the kernel must (almost by definition) interact with some other part of the kernel. Thus someone else than the code owner, being responsible for those other parts of the kernel, can be tasked with signing off on the new code being good and non-malicious. But for NPM or PyPI, where anyone can upload anything, how's that supposed to work? It's perfectly fine for someone to put a package called "removeallfiles" on PyPI which executes "sudo rm -rf /". This isn't (by itself) malicious code. The same code, but obfuscated and put in the package name "isarray", is perhaps obviously malicious. But what about something in the middle, e.g. some form of practical joke package? What central authority decides what is allowed and what is not on PyPI? Signing is a tangential issue. As long as you're trusting the dev who uploaded the code, what difference does it make whether they used password or public key auth (effectively)?
      - raesene3 11y ago
        Well if there's no central validation, that leaves all individual users to validate packages before use (which is a huge amount of work)... The problem is that companies are using these packages as though they are trusted (i.e. not validating them when using them), and that's part of the value proposition in the first place (i.e. it's easier to use this package than write it myself), but it's missing the cost of validation. On signing I'm not sure we're talking about the same thing. I'm referring to developers cryptographically signing packages before pushing to the repository, with a key that the end-user can validate. the idea is to protect against a comrpomise of the repository. There's a good discussion of the risks and potential solutions on The update framework's site (https://theupdateframework.github.io/ https://theupdateframework.github.io/)
        semi-extrinsic 11y ago
        I completely agree on the first two paragraphs. Wrt. signing: I'm assuming we are talking about PyPI and NPM here. Also I'm assuming the major threat vector for a repository compromise is that (some of) the dev's accounts on some other services (most likely email) are somehow compromised. In which case it's down to that dev's OPSEC practices whether the repository can be compromised using the data from $OTHER_SERVICE. If the dev has poor OPSEC and would reuse the password for multiple accounts in a user/pass repo auth scenario, it's reasonable that this person would also have emailed themself the keys for signing packages, e.g. for transferring to another location behind a firewall. In either case, you're down to trusting the dev's OPSEC. IMO, the threat models for other kinds of compromises which signing protects against are much more far fetched. AFAICT neither PyPI nor NPM use third-party mirrors, which basically leaves MitM attacks. If an attacker is capable of successfully MitM-ing the connections you make to PyPI/NPM over https, you have much bigger problems. Or am I missing your point here?
- Silhouette 11y ago
  Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware... It depends on what kind of repository you're trying to build. If you're talking about something like NPM, PyPI or CPAN, then sure, these are relatively open systems where anyone can contribute but that includes bad people. An example from the other end of the spectrum would be Boost for C++, which is heavily curated and peer reviewed, good enough in quality that its libraries sometimes become part of the full C++ standard at a later date, and tiny compared to the others I mentioned before.
- driverdan 11y ago
  I don't think this is unfortunate at all. I shouldn't have to wait for someone to review my code before publishing an important bugfix. This is the primary thing that drove me away from mobile apps.
  - raesene3 11y ago
    On the flip-side how is someone who's using a package from one of these repository meant to validate that it's secure and non-malicious? without central validation, each user would have to do it, and that's frankly impractical... The alternative is that no-one actually does the validation and runs the risk of insecure or malicious packages. To me, that's totally fine as long as they're doing it knowingly, however I'd suggest that most companies making use of NPM, PyPI, Rubygems etc are not doing it knowingly...
mjs 11y ago
On update, can you send email to the purported author, telling them they've updated the package? (Similar to those "you have logged into some site from a new computer" emails.) An easy way to undo a publish would also be useful.
- _asummers 11y ago
  Totally about your first suggestion. But just a reminder, this whole look into NPM began because someone deleted his published packages. Don't know if that's something we should be adding. Deleting versions to me sounds like rebasing public git history.
  - matt_kantor 11y ago
    How about a delay before making the package publicly available so that there could be an undo window? I'm not sure what an appropriate duration would be, as there are obviously situations where someone might want to publish an urgent bugfix quickly. This could also save publishers from their own "whoops" moments, akin to gmail's super-handy "undo send" feature[1]. [1]: https://support.google.com/mail/answer/1284885?hl=en https://support.google.com/mail/answer/1284885?hl=en
ChrisAntaki 11y ago
Looking forward to 2-factor authentication in npm! For what it's worth, I find Google Authenticator offers a user better experience than text message based MFA.
- kvz 11y ago
  Until you lose your phone. There is no way to back up/recover. So it's tied to this particular device forever. This has been reported years ago and never fixed. Use authy or sms.
  - NetStrikeForce 11y ago
    I don't think that's accurate. I've changed phones multiple times and the worst I had to do was find my list of 10 recovery passwords to use one to get in and change the phone I use with Authenticator. Usually I would just login and add the new phone.
    - kiallmacinnes 11y ago
      Agree, I've lost phones with many of my 2FA tokens on it, I pulled out my backup codes and got back into all 10-15 or so sites which I use 2FA on. With the exception of a SMS to a registered phone recovery method, if I can loose my 2FA token, and loose my backup codes, and still access my account, then the 2FA implementation is IMO deeply flawed.
    - deleted 11y ago
      [deleted]
  - chromakode 11y ago
    I just save + encrypt the original QR code somewhere at the time of scanning it.
  - deleted 11y ago
    [deleted]
  - kiallmacinnes 11y ago

raesene3 11y ago

Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware... Linux package managers are a different story of course.

semi-extrinsic 11y ago
Firefox has automated "malware checking" for extensions, the Mozilla AMO Validator, and it's been basically torn to pieces by the community for being not actually secure [1] plus a major hassle for developers [2], to the point that large extensions with hundreds of thousands of users have stopped using the official Firefox extensions repository. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1227867#c2 https://bugzilla.mozilla.org/show_bug.cgi?id=1227867#c2 [2] https://forums.zotero.org/discussion/28847/zotero-addon-is-no-longer-available-at-mozillas-addons/ https://forums.zotero.org/discussion/28847/zotero-addon-is-n...
- raesene3 11y ago
  Yep it's a really nasty problem for any package manager that operates at scale. The problem is that without any centralized validation of packages, it leaves checking to each developer who uses the libraries and obviously from an effort standpoint that just makes it worse (i.e. if it's hard for the repo owner to do validation it's hard x number_of_users for it to be done by end users)
  - semi-extrinsic 11y ago
    The problem is basically how the centralized validation is supposed to work. For e.g. the Linux kernel, it's doable because all code in the kernel must (almost by definition) interact with some other part of the kernel. Thus someone else than the code owner, being responsible for those other parts of the kernel, can be tasked with signing off on the new code being good and non-malicious. But for NPM or PyPI, where anyone can upload anything, how's that supposed to work? It's perfectly fine for someone to put a package called "removeallfiles" on PyPI which executes "sudo rm -rf /". This isn't (by itself) malicious code. The same code, but obfuscated and put in the package name "isarray", is perhaps obviously malicious. But what about something in the middle, e.g. some form of practical joke package? What central authority decides what is allowed and what is not on PyPI? Signing is a tangential issue. As long as you're trusting the dev who uploaded the code, what difference does it make whether they used password or public key auth (effectively)?
    - raesene3 11y ago
      Well if there's no central validation, that leaves all individual users to validate packages before use (which is a huge amount of work)... The problem is that companies are using these packages as though they are trusted (i.e. not validating them when using them), and that's part of the value proposition in the first place (i.e. it's easier to use this package than write it myself), but it's missing the cost of validation. On signing I'm not sure we're talking about the same thing. I'm referring to developers cryptographically signing packages before pushing to the repository, with a key that the end-user can validate. the idea is to protect against a comrpomise of the repository. There's a good discussion of the risks and potential solutions on The update framework's site (https://theupdateframework.github.io/ https://theupdateframework.github.io/)
      - semi-extrinsic 11y ago
        I completely agree on the first two paragraphs. Wrt. signing: I'm assuming we are talking about PyPI and NPM here. Also I'm assuming the major threat vector for a repository compromise is that (some of) the dev's accounts on some other services (most likely email) are somehow compromised. In which case it's down to that dev's OPSEC practices whether the repository can be compromised using the data from $OTHER_SERVICE. If the dev has poor OPSEC and would reuse the password for multiple accounts in a user/pass repo auth scenario, it's reasonable that this person would also have emailed themself the keys for signing packages, e.g. for transferring to another location behind a firewall. In either case, you're down to trusting the dev's OPSEC. IMO, the threat models for other kinds of compromises which signing protects against are much more far fetched. AFAICT neither PyPI nor NPM use third-party mirrors, which basically leaves MitM attacks. If an attacker is capable of successfully MitM-ing the connections you make to PyPI/NPM over https, you have much bigger problems. Or am I missing your point here?
Silhouette 11y ago
Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware... It depends on what kind of repository you're trying to build. If you're talking about something like NPM, PyPI or CPAN, then sure, these are relatively open systems where anyone can contribute but that includes bad people. An example from the other end of the spectrum would be Boost for C++, which is heavily curated and peer reviewed, good enough in quality that its libraries sometimes become part of the full C++ standard at a later date, and tiny compared to the others I mentioned before.
driverdan 11y ago
I don't think this is unfortunate at all. I shouldn't have to wait for someone to review my code before publishing an important bugfix. This is the primary thing that drove me away from mobile apps.
- raesene3 11y ago
  On the flip-side how is someone who's using a package from one of these repository meant to validate that it's secure and non-malicious? without central validation, each user would have to do it, and that's frankly impractical... The alternative is that no-one actually does the validation and runs the risk of insecure or malicious packages. To me, that's totally fine as long as they're doing it knowingly, however I'd suggest that most companies making use of NPM, PyPI, Rubygems etc are not doing it knowingly...

mjs 11y ago

On update, can you send email to the purported author, telling them they've updated the package? (Similar to those "you have logged into some site from a new computer" emails.) An easy way to undo a publish would also be useful.

_asummers 11y ago
Totally about your first suggestion. But just a reminder, this whole look into NPM began because someone deleted his published packages. Don't know if that's something we should be adding. Deleting versions to me sounds like rebasing public git history.
- matt_kantor 11y ago
  How about a delay before making the package publicly available so that there could be an undo window? I'm not sure what an appropriate duration would be, as there are obviously situations where someone might want to publish an urgent bugfix quickly. This could also save publishers from their own "whoops" moments, akin to gmail's super-handy "undo send" feature[1]. [1]: https://support.google.com/mail/answer/1284885?hl=en https://support.google.com/mail/answer/1284885?hl=en

ChrisAntaki 11y ago

Looking forward to 2-factor authentication in npm! For what it's worth, I find Google Authenticator offers a user better experience than text message based MFA.

kvz 11y ago
Until you lose your phone. There is no way to back up/recover. So it's tied to this particular device forever. This has been reported years ago and never fixed. Use authy or sms.
- NetStrikeForce 11y ago
  I don't think that's accurate. I've changed phones multiple times and the worst I had to do was find my list of 10 recovery passwords to use one to get in and change the phone I use with Authenticator. Usually I would just login and add the new phone.
  - kiallmacinnes 11y ago
    Agree, I've lost phones with many of my 2FA tokens on it, I pulled out my backup codes and got back into all 10-15 or so sites which I use 2FA on. With the exception of a SMS to a registered phone recovery method, if I can loose my 2FA token, and loose my backup codes, and still access my account, then the 2FA implementation is IMO deeply flawed.
  - deleted 11y ago
    [deleted]
- chromakode 11y ago
  I just save + encrypt the original QR code somewhere at the time of scanning it.
- deleted 11y ago
  [deleted]
- kiallmacinnes 11y ago