4 ms·

So I can make a malicious module called expres and another one called expresss and screw with ppls machines?

by akamel 10y ago

lima 10y ago
This. Installing modules from npm is dangerous enough. Nice for education or playing around, unsuitable for a serious developers' workstation. Related: http://incolumitas.com/2016/06/08/typosquatting-package-managers/ http://incolumitas.com/2016/06/08/typosquatting-package-mana...
micaksica 10y ago
This. I love that the Node community enjoys innovating for convenience, but ideas like this one are less than half-baked from a security perspective. Just make a few typo'd popular packages, and use npm install scripts [1] and you have a very easy remote code execution vector on developer workstations. The bigger problem I see is that npm is a circus. No package signing and a ridiculous debate on why that's been going on for a year and a half [2]. Credentials leaks of popular modules. [3] When everything is a module and everyone is supposed to include modules vs. writing their own very simple functionality for things even like isArray polyfills [4] (24MM downloads a month!), you end up with the same attack surface that gives WordPress such a shitty reputation for security. It's not usually core, it's all the plugins by authors of unknown provenance and skill. WordPress gets pwned because there are a lot of plugins hastily written by new developers and used without audit by mom-and-pop web app shops and/or those that trust the code because they aren't capable of auditing it meaningfully. When you use an npm dependency, you are taking on all of their dependencies. You are trusting they don't leak creds, that npm has not been compromised, and that the chain underneath has been audited for malicious behavior. In reality this is impractical: go npm install express and see just how deep the dependency chain goes. Things like Snyk are required to just understand what might be vulnerable. [1] https://docs.npmjs.com/misc/scripts https://docs.npmjs.com/misc/scripts [2] https://github.com/node-forward/discussions/issues/29 https://github.com/node-forward/discussions/issues/29 [3] https://github.com/ChALkeR/notes/blob/master/Do-not-underestimate-credentials-leaks.md https://github.com/ChALkeR/notes/blob/master/Do-not-underest... [4] https://www.npmjs.com/package/isarray https://www.npmjs.com/package/isarray EDIT: Ironically, this module itself is vulnerable to code injection.
- yid 10y ago
  > It's not usually core, it's all the plugins by authors of unknown provenance and skill. This is otherwise known as an active developer community and is a good thing. In any open library ecosystem, it's ultimately up to the developer to carefully choose and vet third-party modules. There isn't any substitute for that. The alternative is a tightly controlled standard library, but that isn't npm's stated goal. Such a controlled, curated, audited standard library is, however, something that could be built on top of npm, but obviously not vice versa. So npm being a circus is, in the grander scheme of things, a good thing. Novice programmers will necessarily produce novice code. edit: if it wasn't clear, I completely agree about the security risks of this project.
  - Frondo 10y ago
    What kind of vetting is occurring when you're automatically installing npm modules as you code? But, "Novice programmers will necessarily produce novice code." Having had my own variety of experience with CPAN, PEAR, Tcl's package thing, C by way of building my own RPMs and DEBs, and now watching the ongoing trainwreck that is npm, yes. You're right about that.
  - micaksica 10y ago
    > The alternative is a tightly controlled standard library, but that isn't npm's stated goal. What npm says it is doing on paper and in its charter is not necessarily what npm gets used for. At this point in the ecosystem's maturity, npm developers are doing their users a massive disservice and opening them up to a lot of risk. Maintaining this line of a vibrant active community, and "developers should be responsible for their own security", rings hollow. As I see it, npm appears to be acting like there are a lot of unsolved problems in this realm, and in doing so are endangering a developer community that is absolutely full of amateurs. I would argue that JavaScript is the most accessible language of the current era, and Node.js is being pushed by a lot of third parties as the new easy way into programming. These new guys don't know security and want to contribute to the community, and the npm gatekeepers seem to be doing little to stop naïveté from causing virus-like consequences in their dependency chains. When I was a teenager writing code I had no idea what security issues I needed to patch against. I wasn't educated on it and didn't care. I just wanted to make cool stuff. The problem with npm is that the cost of entry of your "cool stuff" into the hands of a thousand trusting others is too low; there is no delineation between what is authoritative and what isn't. Debian solved this problem years ago. Restrict npm defaults to vetted packages, and have people add repositories as need be (e.g. multiverse, Ubuntu PPA, etc.) for packages that aren't audited or by trusted parties. The Node user experience often ignores most security issues for ease of use; this is OK when you are guarding people against the most likely mistakes. This is a problem of setting insecure defaults and expecting the Internet to play nice. The user experience, the marketing message, and the community at large defends its openness to the death. I'm all for openness, but at some point senior developers should be attempting to shepherd their new developers into making secure decisions, and thinking in a way that is somewhat security minded.
tolmasky 10y ago
This is one of the benefits of using a container-based system like the one we designed for https://tonicdev.com https://tonicdev.com . On Tonic, you get the same conveniences displayed here (actually better since all the packages already exist, so no install-wait time), but the entire development process happens in a container. Once you're ready to move on, you can download the project with shrink-wrap to get identical behavior, but until then you can more freely try whatever you'd like.
rajington 10y ago
I wonder what https://tonicdev.com/ https://tonicdev.com/ does.

So I can make a malicious module called expres and another one called expresss and screw with ppls machines?

by akamel 10y ago

So I can make a malicious module called expres and another one called expresss and screw with ppls machines?

lima 10y ago

This. Installing modules from npm is dangerous enough. Nice for education or playing around, unsuitable for a serious developers' workstation. Related: http://incolumitas.com/2016/06/08/typosquatting-package-managers/ http://incolumitas.com/2016/06/08/typosquatting-package-mana...

micaksica 10y ago

This. I love that the Node community enjoys innovating for convenience, but ideas like this one are less than half-baked from a security perspective. Just make a few typo'd popular packages, and use npm install scripts [1] and you have a very easy remote code execution vector on developer workstations. The bigger problem I see is that npm is a circus. No package signing and a ridiculous debate on why that's been going on for a year and a half [2]. Credentials leaks of popular modules. [3] When everything is a module and everyone is supposed to include modules vs. writing their own very simple functionality for things even like isArray polyfills [4] (24MM downloads a month!), you end up with the same attack surface that gives WordPress such a shitty reputation for security. It's not usually core, it's all the plugins by authors of unknown provenance and skill. WordPress gets pwned because there are a lot of plugins hastily written by new developers and used without audit by mom-and-pop web app shops and/or those that trust the code because they aren't capable of auditing it meaningfully. When you use an npm dependency, you are taking on all of their dependencies. You are trusting they don't leak creds, that npm has not been compromised, and that the chain underneath has been audited for malicious behavior. In reality this is impractical: go npm install express and see just how deep the dependency chain goes. Things like Snyk are required to just understand what might be vulnerable. [1] https://docs.npmjs.com/misc/scripts https://docs.npmjs.com/misc/scripts [2] https://github.com/node-forward/discussions/issues/29 https://github.com/node-forward/discussions/issues/29 [3] https://github.com/ChALkeR/notes/blob/master/Do-not-underestimate-credentials-leaks.md https://github.com/ChALkeR/notes/blob/master/Do-not-underest... [4] https://www.npmjs.com/package/isarray https://www.npmjs.com/package/isarray EDIT: Ironically, this module itself is vulnerable to code injection.

yid 10y ago
> It's not usually core, it's all the plugins by authors of unknown provenance and skill. This is otherwise known as an active developer community and is a good thing. In any open library ecosystem, it's ultimately up to the developer to carefully choose and vet third-party modules. There isn't any substitute for that. The alternative is a tightly controlled standard library, but that isn't npm's stated goal. Such a controlled, curated, audited standard library is, however, something that could be built on top of npm, but obviously not vice versa. So npm being a circus is, in the grander scheme of things, a good thing. Novice programmers will necessarily produce novice code. edit: if it wasn't clear, I completely agree about the security risks of this project.
- Frondo 10y ago
  What kind of vetting is occurring when you're automatically installing npm modules as you code? But, "Novice programmers will necessarily produce novice code." Having had my own variety of experience with CPAN, PEAR, Tcl's package thing, C by way of building my own RPMs and DEBs, and now watching the ongoing trainwreck that is npm, yes. You're right about that.
- micaksica 10y ago
  > The alternative is a tightly controlled standard library, but that isn't npm's stated goal. What npm says it is doing on paper and in its charter is not necessarily what npm gets used for. At this point in the ecosystem's maturity, npm developers are doing their users a massive disservice and opening them up to a lot of risk. Maintaining this line of a vibrant active community, and "developers should be responsible for their own security", rings hollow. As I see it, npm appears to be acting like there are a lot of unsolved problems in this realm, and in doing so are endangering a developer community that is absolutely full of amateurs. I would argue that JavaScript is the most accessible language of the current era, and Node.js is being pushed by a lot of third parties as the new easy way into programming. These new guys don't know security and want to contribute to the community, and the npm gatekeepers seem to be doing little to stop naïveté from causing virus-like consequences in their dependency chains. When I was a teenager writing code I had no idea what security issues I needed to patch against. I wasn't educated on it and didn't care. I just wanted to make cool stuff. The problem with npm is that the cost of entry of your "cool stuff" into the hands of a thousand trusting others is too low; there is no delineation between what is authoritative and what isn't. Debian solved this problem years ago. Restrict npm defaults to vetted packages, and have people add repositories as need be (e.g. multiverse, Ubuntu PPA, etc.) for packages that aren't audited or by trusted parties. The Node user experience often ignores most security issues for ease of use; this is OK when you are guarding people against the most likely mistakes. This is a problem of setting insecure defaults and expecting the Internet to play nice. The user experience, the marketing message, and the community at large defends its openness to the death. I'm all for openness, but at some point senior developers should be attempting to shepherd their new developers into making secure decisions, and thinking in a way that is somewhat security minded.

tolmasky 10y ago

This is one of the benefits of using a container-based system like the one we designed for https://tonicdev.com https://tonicdev.com . On Tonic, you get the same conveniences displayed here (actually better since all the packages already exist, so no install-wait time), but the entire development process happens in a container. Once you're ready to move on, you can download the project with shrink-wrap to get identical behavior, but until then you can more freely try whatever you'd like.

rajington 10y ago

I wonder what https://tonicdev.com/ https://tonicdev.com/ does.