npm is finally going to disable postinstall scripts by default in the next major version at least, copying what other JS package managers like pnpm do. They also added a setting for minimum age (only install package versions that are at least X days old) which is meant to help too - the idea being that malware will have been detected and removed before anyone installs it.
People use third-party Linux package repos all the time though, and they have similar attack vectors. If I can convince you to add my Debian/RPM/whatever repo, I can create a package with the same name as a common one but with a newer version number, and apt upgrade will happily replace the official package with my malicious one.
This is intentional for several reasons (e.g. deb.sury.org has PHP packages that replace the official Debian ones) but I’m really surprised we don’t see more supply chain attacks via third party deb/rpm repos.
Maybe it’s because the barrier to entry is higher? With a custom deb repo (either self-hosted or using something like Packagecloud or Ubuntu PPA), you need to create the repo, create Debian packages, add them to the repo (eg using Aptly), GPG sign the repo, and convince people to add the repo. npm is just one repo with everything in it.
When I’m looking for a package that’s not in the official repos, I add only either popular repos with active maintainers who do regular updates or ones from packagers I know personally.
First one is hard to fake for obvious reasons. I guess someone could try to know me personally and somehow engineer a situation where I would want to have a piece of software that they package, but that’s arguably even harder to pull off and is certainly not worth it for stealing one nerd’s worth of money.
not only do you have to setup the infrastructure to host multiple repositories (deb, rpm), you also have to build and deploy multiple packages of sufficient quality that you don’t break something else, which for a common/popular package would make the malware immediately noticeable.
npm is finally going to disable postinstall scripts by default in the next major version at least, copying what other JS package managers like pnpm do. They also added a setting for minimum age (only install package versions that are at least X days old) which is meant to help too - the idea being that malware will have been detected and removed before anyone installs it.
People use third-party Linux package repos all the time though, and they have similar attack vectors. If I can convince you to add my Debian/RPM/whatever repo, I can create a package with the same name as a common one but with a newer version number, and
apt upgradewill happily replace the official package with my malicious one.This is intentional for several reasons (e.g.
deb.sury.orghas PHP packages that replace the official Debian ones) but I’m really surprised we don’t see more supply chain attacks via third party deb/rpm repos.Maybe it’s because the barrier to entry is higher? With a custom deb repo (either self-hosted or using something like Packagecloud or Ubuntu PPA), you need to create the repo, create Debian packages, add them to the repo (eg using Aptly), GPG sign the repo, and convince people to add the repo. npm is just one repo with everything in it.
Convincing people to use it is also hard.
When I’m looking for a package that’s not in the official repos, I add only either popular repos with active maintainers who do regular updates or ones from packagers I know personally.
First one is hard to fake for obvious reasons. I guess someone could try to know me personally and somehow engineer a situation where I would want to have a piece of software that they package, but that’s arguably even harder to pull off and is certainly not worth it for stealing one nerd’s worth of money.
not only do you have to setup the infrastructure to host multiple repositories (deb, rpm), you also have to build and deploy multiple packages of sufficient quality that you don’t break something else, which for a common/popular package would make the malware immediately noticeable.