Contao Manager 1.10 - composer.lock Validation

After the Contao Manager has already received new security features with version 1.9.0, we are now going one better with version 1.10!

Note: It's about to get a bit technical, but unfortunately there's no other way for this version.
The short version, in case it's a bit too detailed for you: Version 1.10 is now even more secure and now also prevents certain man-in-the-middle attacks.

Basics: Package management

The basic function of the Contao Manager is to install, update and, of course, remove extensions (or simply “packages” in general Composer language).

There are two fundamentally different types of information in package management, which are technically managed by Composer in two different files and displayed visually by the Contao Manager:

• In the composer.json you determine what you need (e.g. “I want Contao, version 5.3 or higher but never a version 6”). So for those familiar with Composer, ^5.3.
• The composer.lock, on the other hand, determines what you get (e.g. “You get Contao version 5.3.33”).

Or to put it another way:

composer.json = shopping list with approximate information
composer.lock = shopping basket with exact products

Composer takes over the task of determining the best possible combination of all packages from the information in your composer.json and their dependencies and then records this in the composer.lock.
Once the package information (not only the versions but also the URLs where these packages can be downloaded, for example) has landed in the composer.lock, no further validation takes place.

Would you like to deepen your knowledge? Then I can recommend the following article composer.json - Understanding version constraints and dependencies. In it, Christian explains the topic of version constraints and gives you tips on how to deal with error messages if certain versions cannot be installed.

The Composer Resolver Cloud and the Contao Manager API

When updating the packages, the Contao Manager uses the Composer Resolver Cloud by default. This is simply because resolving the dependencies potentially requires more RAM than is available on your hosting.
The Cloud responds with the final composer.lock, the contents of which the Contao Manager then installs via Composer. The information is therefore processed unchecked.
If an attacker were to manage to take over the Composer Resolver Cloud, they could inject you with a malicious package. Most likely in such a way that you would never notice it.

But that's not all. The Contao Manager also has an interface (API) with which composer.json or composer.lock files can be sent directly to the Contao Manager and thus an installation can be updated or changed.
One such service that uses this API is, for example, trakked.io. There too, if an attacker manages to infiltrate the service, they could inject you with unwanted packages.

The solution: Validation of the composer.lock

Driven by this attack vector, we have spent the past few weeks working on a validation library that is able to check whether the content of a composer.lock matches the definition of the composer.json and the configured repositories.
The result is terminal42/composer-lock-validator which correctly recognizes various attack scenarios. It is therefore no longer possible:

• To add packages although they are not mentioned in the composer.json.
• To add packages although they are not required by any other package.
• To remove packages that should be there.
• To change the metadata of a package.

The just released Contao Manager in version 1.10 now uses this library everywhere and prevents this attack vector from now on!
So even if you don't use a service that makes use of the API, you are now protected from the danger of a hostile takeover of the Composer Resolver Cloud.

Keep updating packages and have fun doing so much more securely! 😎 🔐