61–70 of 100 posts
So this doesn't strike me as an npm issue but something more fundamental: there is no easy way on any platform to define a set of rules for processes I invoke via the command line. Like, it would be really really nice if I could wrap npm so it can only write to $HOME/.npm, /tmp and the current working directory - but I know of no system which will currently let me do that suitably dynamically.
Earlier quoted context omitted.
I often wonder about the results of people using functional hostnames in their examples. Most PoC exploit code use "target.com" as a place holder which makes sense, but hilariously is also the hostname for US retailer Target...
This is exactly the reason example.com exists
This applies to pretty much every pkg manager ever created. That's why it's important to have end-to-end package signing with a reasonable UI, so people can choose to selectively trust the sources they need and get alerted before new dependencies get pulled in. Sadly I don't know of any pkg manager that implements this correctly.
> This applies to pretty much every pkg manager ever created. (noob question) Does it apply to PyPi/pip also?
It's not just Npm, RubyGems has essentially the same issue. I think the real lesson is "be careful what you install".
But do they need to have the issue? Why allow running arbitrary commands during install? To me it is less about someone purposely including malicious code (since yes, that could be in the project itself not just the install) but that having this willy-nilly form of package managing opens up people to mistakes moving files around that do harm on accident. And it gets even worse if the package is able to be added to a…
I could just as easily embed something like that in any code on any open source project in any language as part of the installer or the main code base.
Bingo... pretty trivial to stick an `rm -rf /*` shell call somewhere in your code. Not sure what difference it makes whether it's in a package manager file, or the code. Lesson... read the code before running it. Title of the post should be "Running code you haven't read can be dangerous"
This applies to pretty much every pkg manager ever created. That's why it's important to have end-to-end package signing with a reasonable UI, so people can choose to selectively trust the sources they need and get alerted before new dependencies get pulled in. Sadly I don't know of any pkg manager that implements this correctly.
This seems a bit more dangerous... to do this with apt, you need to MITM, since the Debian repos are ultimately checked by ftpmasters to make sure (amongst other things) that packages like rimrafall don't get in. Apt also has mitigations against MITM, as described elsewhere in this thread.
Who's checking what packages make it into npm? How did rimrafall get accepted as a package?
Somehow I feel like using something that just simulates rm -rf /* would have brought the point across just as well and a bit safer...
npmjs still contains the package: https://www.npmjs.com/search?q=rimrafall https://www.npmjs.com/package/rimrafall '0 downloads in the last month' There is no 'report package' button. The support link goes to a 'we are hiring' contact form. Report bad packages as security issues? https://www.npmjs.com/security Package signing. Review process. Scanning tools for dangerous packages. As a user, don't trust anything and…
This seems like an impossible problem (essentially the halting problem). On Linux perhaps you could build packages in a container then copy the results to the installation directory, but there's no guarantee require("rimrafall") won't just "child_process.exec('rm -rf /')".
This is exactly why i think modern kernel level security layers, such as FreeBSD jails (or Docker/LXC) were born. Provided your app runs within a jail, it wouldn't matter much anymore: > Once inside the jail, a process is not permitted to escape outside of this subtree You could also develop within isolation, therefore your development env would be safer and even similar to a production environment. Needless to say,…
I always develop inside a virtual machine, with a shared folder in between so I can write code on the host, but everything runs in the guest.
Huzzah for git.
This applies to pretty much every pkg manager ever created. That's why it's important to have end-to-end package signing with a reasonable UI, so people can choose to selectively trust the sources they need and get alerted before new dependencies get pulled in. Sadly I don't know of any pkg manager that implements this correctly.