Blast from the Past

PEAR?

Back in 1999, in the months leading up to the release of PHP 4, Stig Sæther Bakken started to work on PEAR, the PHP Extension and Abstraction Repository that was later renamed to PHP Extension and Application Repository. PEAR was conceived as a "CPAN for PHP". CPAN is the "Comprehensive Perl Archive Network", a repository of software packages written in the Perl programming language.

Initially, PEAR only referred to the repository of PHP software packages hosted at pear.php.net . These packages were developed in a CVS repository on cvs.php.net . But PEAR was more than just software packages developed and distributed using official PHP project infrastructure resources. For one thing, rules were put into place. Duplicates were not allowed, for instance, meaning that if a package for solving a particular problem already existed in PEAR then a new package that wanted to solve the same problem was not allowed. New packages were voted upon before they were accepted into PEAR. Notable and widely used PEAR packages are MDB2 and HTML_QuickForm, for instance. In addition, some popular PHP development tools such as PHPUnit, PHP_CodeSniffer, or phpDocumentor at least started off being a PEAR package.

PEAR was created in the PHP 4 era. At the time, the PHP programming language did not have proper support for object-oriented programming yet. The PEAR package was created to provide standard implementations to overcome limitations of the language. For instance, emulation of exceptions and destructors was provided. Using these emulation layers was required of any PEAR package, so all PEAR packages depended on this "core" PEAR package. Any software that used a package from PEAR needed to handle errors triggered by that dependency and therefore had to be aware of the implementation details of PEAR's exception emulation. Therefore PEAR was more than just a package repository: it was an environment your application had to be aware of.

Years later, Greg Beaver needed a solution to distribute and install phpDocumentor and kicked off the development of the PEAR Installer. This command-line tool was able to automatically download, install, and update PEAR packages. Since then the term PEAR referred both to the repository of PHP software packages hosted at pear.php.net as well as to the PEAR Installer, pear on the CLI, that acted as an interface to the repository and as a package manager. The PEAR Installer installed packages globally to a directory that had to be on PHP's include_path . This approach has many drawbacks compared to project-local installation of dependencies. For instance, all projects being worked on a developer's machine or hosted on a server have the same version of a particular package: using version X of a package in one project and version Y in another is impossible.

Later support for alternative package repositories other than pear.php.net , so-called channels, was added to the PEAR Installer. This allowed developers to distribute their software in such a way that it was installable through the established PEAR Installer while not being subject to PEAR's governance and rules. Initially, though, almost nobody created their own channel server as the setup process required for that was rather painful. Only after Fabien Potencier released Pirum, an alternative tool for setting up such a server, hosting your own PEAR channel became feasible.

In 2011, Nils Adermann was looking for a solution to install the phpBB software as well as plugins for it. Together with Jordi Boggiano he started to work on Composer, a project-level dependency manager. By 2014, the developers of popular PEAR packages were at least thinking about stopping to distribute their software a PEAR packages . PEAR 2 ("Project Pyrus") was an attempt to rewrite PEAR's core and to update it for PHP 5.3. This effort did not succeed, though. We can only speculate, but think it is safe to assume that the rise of Composer was in fact one of the main reasons.

PEAR was a significant driver for the professionalization of PHP as it provided a standardized way for installing and updating dependencies, and for that, the PHP community owes a great deal of respect and gratitude to the PEAR project.

The go-pear.phar Incident

Why are we writing about PEAR in 2019? Because something bad has happened:

What happened?

There was a security breach on the pear.php.net server and the go-pear.phar file that was hosted at https://pear.php.net/go-pear.phar was replaced by a version containing malware which opens a reverse shell via Perl. This security breach happened sometime between December 20, 2018 when the file in question was last updated by a maintainer and January 18, 2019 when the malware was reported to the PEAR maintainers. The malware was verified and the incident was made public by the PEAR maintainers on January 19, 2019.

It is important to note that go-pear.phar is not the PEAR Installer itself. It is a small PHP application, packaged as a PHP Archive (PHAR), that is used to bootstrap a PEAR environment, including the PEAR Installer. This means that the security breach affects systems that used https://pear.php.net/go-pear.phar to set up a new PEAR environment between December 20, 2018 and January 19, 2019.

Am I affected?

You are not affected if you do not use PEAR, install(ed) PEAR through your operating system's package manager, install(ed) PEAR manually without using go-pear.phar , and did not use a go-pear.phar downloaded between December 20, 2018 and January 19, 2019.

If you downloaded go-pear.phar between December 20, 2018 and January 19, 2019 and used it on a system that has sh and perl available then you must consider that system to be compromised, and take responsible action.

If you do not know whether you have automation in place at your organization that, for instance as part of continuous integration, uses a freshly downloaded go-pear.phar to set up a clean PEAR environment then you might be affected and should, for instance, scan your network for traffic to pear.php.net to find such jobs.

Of course, if you do not have PEAR at all in your PHP environment then you are guaranteed to be safe.

Why was PEAR attacked?

Programs that install software, including software such as go-pear.phar that installs software that installs software, are worthwhile targets for attacks such as the one described above. Instead of attacking multiple systems you only need to (successfully) attack one system, in this case pear.php.net , replace the installer, in this case go-pear.phar , with a malware, and (ab)use the existing distribution infrastructure to multiply your attack. Instead of owning a single system you will basically own each and every system that installs the installer you replaced.

The attack on go-pear.phar is not the first of its kind and, unfortunately, it is unlikely to be the last. Similar attacks in the past affected Debian , Python , or JavaScript , just to name a few.

Could the attack have been prevented?

The fundamental problem is that users are encouraged by documentation to "cURL and pipe to bash" by copying and pasting commands such as

into their shell. This prevents any verification of authenticity and integrity of the downloaded executable before running it. Users doing this are literally asking for their system to be compromised!

The PEAR documentation instructed the user to run

which is just as bad because it instructs users to skip verification.

But even if a user would have wanted to verify the file before running it, this would not have been possible because the PEAR project did not publish any cryptographic signatures. This is definitely not up to current security standards.

Looking at the PEAR Installer itself one can see that the PEAR project was, at least in principle, aware of this problem: the pear sign command can be used to optionally sign a PEAR package using a GPG key before distribution. To the best of our knowledge, though, the PEAR Installer never used this signature to verify a package before installation.

In general, attacks on computer systems cannot be prevented. One can only implement measures that make it harder, and thus less attractive, to attack a system. What can be prevented, though, is that it takes a long time to detect an attack and then to recover from it. It is not enough to have intrusion detection and monitoring in place. Just like the server itself, these measures need to be maintained. And if they detect an anomaly then somebody needs to react to that event. This requires time and effort, essentially human resources. Especially for Open Source projects, where all work is done by volunteers, this is often a problem.

Why is pear.php.net still down?

Today far fewer developers and projects use packages from PEAR and the PEAR Installer to manage them than five years ago, when Composer became increasingly popular. This decline in usage of the PEAR Installer and the pear.php.net infrastructure motivates fewer and fewer volunteers to keep PEAR alive.

When they verified and announced the go-pear.phar malware on January 19, 2019, the remaining PEAR maintainers decided to take pear.php.net offline. They are in the process of rebuilding the server but there is no estimate on when (and maybe even if) the PEAR infrastructure will be back online. In that regard the current outage of pear.php.net is not unlike a situation back in 2015 when the server's hard disk crashed and it took a while to get it up and running again.

By the way: an unexpected side effect of the pear.php.net outage is the fact that TravisCI is unable to update its nightly builds of PHP 7.4 because the PHP build script wants to download go-pear.phar which, of course, does not work at the moment.

Is PEAR still relevant?

Most of the PHP community has moved on and neither uses the PEAR Installer nor packages from PEAR anymore.

For example, the PEAR channel server that was used to distribute PHPUnit for a long time, pear.phpunit.de , was turned off over four years ago. However, every hour dozens of requests from PEAR Installer clients are made to pear.phpunit.de . A month before pear.phpunit.de was turned off, PHPUnit 3.7.36 and PHPUnit 4.0.18 were released as PEAR packages. These did not install a working version of PHPUnit. They merely installed a script that printed an error message. With that in mind, one has to wonder how many PEAR Installer clients out there are "zombies" that perform automated tasks that nobody knows about anymore.

Although the majority of PEAR packages was never updated for PHP 5, let alone for PHP 7, even the current PHP releases bundle PEAR and --without-pear has to be configured when you build PHP from its sources yourself to prevent the installation of a PEAR environment. This might convey the impression that the PHP Project considers the PEAR Installer to be the official package manager for PHP. This is not the case.

The only reason why PHP releases still want to install PEAR by default is that it is required for the PECL Installer, pecl on the CLI, to work. This is used to automatically download, compile, and install extensions for the PHP runtime that are written in C or C++ from pecl.php.net . Whereas Composer has clearly superseded and replaced the PEAR Installer, it seems that the PECL Installer is still relevant. It appears that it is commonly used in Dockerfiles and as part of PHP support in Homebrew on macOS.

Conclusion

There are lessons to be learned here that also apply to commercial software projects. Bruce Schneier once wrote: "Security is a process, not a product" . This metaphor is not limited to just security: you must not think of upgrading your PHP stack as a "special project" but instead make this a part of your normal operational procedure , for instance.

A lot of software has not been touched in years and it is not uncommon for a company to not know exactly which applications are (still) running on their infrastructure. They were set up, maybe even purchased from a third-party as a turn-key solution, at some point in the past and then were forgotten. These applications are not monitored and nobody feels responsible for them. Maybe, through an attack such as the one discussed in this article, the servers operating these applications have been compromised already years ago. This is irresponsible, and not just since the GDPR came into effect.

It would be too short-sighted to just put blame for the attack on the PEAR project. Clearly, the maintainers of PEAR should have provided signatures to verify go-pear.phar . Likely, they did not pay enough attention to the pear.php.net server to notice earlier that it was compromised. But every user that downloads a file from the internet and executes it without verification deserves an equal share of the blame.

If the PEAR project lacks the human resources to ensure the safe and secure operation of pear.php.net as well as related infrastructure and software then maybe they should acknowledge that fact and as a consequence come up with a plan to retire PEAR.

We can help you

Existing systems primarily age because technology evolves. In the long run, the safe, secure, and smooth operation of software is only possible on up-to-date systems. We can support you in finding out whether you are still using PEAR on your systems as well as with your software's migration to PHP 7 .

You can find more information on how we can help you in dealing with your legacy software as well as operating your PHP applications on our website.