In a blog post published by Nils Adermann co-Founder of Packagist, explained how composer manage dependency confusion and avoid security issues caused by other package managers to big companies such Apple, Microsoft, and dozen of others companies.
A quick hack to other package managers such as npm (Javascript), pip (Python), and gems (Ruby) allow to get companies to install and run his malicious code on their infrastructure by easily using their internal package name and upload online a higher version number with the same name.
The companies then installed and ran these malicious packages instead of their internal packages because their package manager chose the higher version number from the default package repository over their internal repository.
Jordi Boggiano explained on twitter how Packagist and composer prevent such security issues :
- Composer package names always include a vendor prefix, e.g. “my-company/our-internal-pkg”. This naming is strictly enforced by the command line utility and on packagist.org. Packagist.org reserves vendor name prefixes for the maintainer as soon as they publish a first package. Nobody else can then publish another package with the my-company/ vendor prefix without a maintainer’s consent.
- As of Composer 2.0 custom repositories are canonical by default. This means that if a package name is found in a custom or private package repository, only those versions are loaded at all. If the same package name exists on lower priority repositories or on packagist.org, it is ignored. Even if an attacker publishes a package by the same name as your internal package with a higher version number, Composer will not install it.
- Private Packagist has always treated third party mirrored repositories including packagist.org as canonical and never loaded package information from mirrors if a private package by that name exists. So Private Packagist protects users on Composer 1.x in the same way as Composer 2 now does by default.
- Private Packagist allows you to manually approve each newly mirrored package from a third party repository like packagist.org before it can be installed with Composer. This is an optional feature to give customers even more control over the third party code they use.
- Composer always generates a lock file with list of the concrete versions and download URLs of dependencies installed. We strongly recommend you commit the lock file to a version control system and only use composer install during build steps, which will only ever install the exact versions listed in the lock file. You can make reviewing changes to the lock file a part of your regular workflows to ensure code is not loaded from untrusted third parties.
- With Composer 2 you can exclude package names or patterns from loading for each repository. So you can ensure even mistyped non-existent packages without a registered prefix on packagist.org cannot be loaded from packagist.org by replacing the default configuration in composer.json. The exclude filter can be used on additional third party package repositories too.
All of these, made attacks described by Alex Birsan and that hit big companies, not possible to reproduce reproduce easily for PHP. Dependency chain attacks are serious threat to most companies today as most applications depends on many packages and usually multiples package managers are used. So PHP developers and businesses should be aware of this, and take the necessary measures to protect their applications from malicious code injection.
