More of a joke but:
npm install virus.exe
Perfect for the #scalenpm tshirts
Npm install could be dangerous
51–60 of 100 posts
Re: Npm install could be dangerous
#52This 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.
What do you find wrong with the yast/zypper's RPM repo signing methods? I've never seen it add a repo without prompting to accept the signing keys before adding it.
Re: Npm install could be dangerous
#53This 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?
Re: Npm install could be dangerous
#54Earlier quoted context omitted.
I find the apt package model to be very good (add trusted keys & repositories explicitly). What do you see as the shortcomings of apt compared to your ideal?
I'm not OP, but my opinion would be that APT does do some things better than npm etc but there's still some potential problems. Probably one of the most obvious is that access to the repos is over unencrypted HTTP connections which opens the process up to tampering (depending on the attacker) for example injecting an older version of a package with a known security issue.
I guess its actually the package distribution that makes a difference, an apt package such as rimrafall won't ever reach an official debian repository. So in the context of adversary package code execution the weak spot is actually the npm registry policy and not npm packaging it self.
Re: Npm install could be dangerous
#55npmjs 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…
that's interesting. Any pointers to package stores that do a better job on security? I'm researching the area a bit at the moment and I've not seen a lot of good practice out there, so would be interesting to have some good examples to hold up.
Fedora and RHEL have had mandatory signing since before either existed (back when it was RHL).
Debian has had what we'd call 'EV' level security these days for about 15 years - people bringing their passports in and reading out their GPG public keys at LUGs.
Re: Npm install could be dangerous
#56Slight OT: does anyone know of any hacking/malware campaigns that were specifically aimed at developers (but not against a specific company)? Normal trojans sometimes steal game keys, I could imagine searching the disk for AWS keys might be profitable, too?
Re: Npm install could be dangerous
#57If you run npm with root, npm will run scripts with the user "nobody" by default. This means that npm doesn't run scripts as root even if you run "npm install" with root.
You can set another user instead of nobody with the "user" option and you can disable switching UID/GID using the "unsafe-perm" option but DO NOT DO THIS.
More information here: https://docs.npmjs.com/misc/config
edit: added more details.
Re: Npm install could be dangerous
#58Earlier quoted context omitted.
I find the apt package model to be very good (add trusted keys & repositories explicitly). What do you see as the shortcomings of apt compared to your ideal?
I'm not OP, but my opinion would be that APT does do some things better than npm etc but there's still some potential problems. Probably one of the most obvious is that access to the repos is over unencrypted HTTP connections which opens the process up to tampering (depending on the attacker) for example injecting an older version of a package with a known security issue.
> for example injecting an older version of a package with a known security issue
There's a limited window during which an attack like this will work. If you look at one of the Release files [1], you'll notice the pseudo-header:
Valid-Until: Wed, 04 Feb 2015 16:41:23 UTC
E: Release file for http://mirrors/debian/dists/wheezy-updates/Release is expired (invalid since 1h 24min 32s). Updates for this repository will not be applied.
You could also choose one of the mirrors that supports HTTPS, like mirrors.kernel.org or mirrors.ocf.berkeley.edu (both good for Bay Area folks).
(Granted, the window is probably larger than we'd like, though you could write a script to check that if you wanted. Something like [2] would work.)
[1] http://mirrors.ocf.berkeley.edu/debian-security/dists/wheezy... [2] https://github.com/ocf/puppet/blob/master/modules/ocf_mirror...
Re: Npm install could be dangerous
#59Earlier quoted context omitted.
I find the apt package model to be very good (add trusted keys & repositories explicitly). What do you see as the shortcomings of apt compared to your ideal?
I'm not OP, but my opinion would be that APT does do some things better than npm etc but there's still some potential problems. Probably one of the most obvious is that access to the repos is over unencrypted HTTP connections which opens the process up to tampering (depending on the attacker) for example injecting an older version of a package with a known security issue.
I'm fairly certain there's some protection against that sort of attack. A quick google brings me to [1] which seems to indicate that the Release file has a 7-day expiration period. Having apt connect over unencrypted HTTP allows for caching options that npm doesn't. It's also not dependant on the shitty SSL CA system.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499897
Re: Npm install could be dangerous
#60So 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.