A security breach has been found on the webserver, with a tainted go-pear.phar discovered.
The PEAR website itself has been disabled until a known clean site can be rebuilt. A more detailed announcement will be on the PEAR Blog once it's back online.
If you have downloaded this go-pear.phar in the past six months, you should get a new copy of the same release version from GitHub (pear/pearweb_phars) and compare file hashes. If different, you may have the infected file.
A new v1.10.10 release of pearweb_phars is available on
@github
. This rereleases the correct `go-pear.phar` as v1.10.9, the file that was found tainted on the `` server, and now includes separate GPG signature files with each `phar`.
1/5 What we know: the tainted go-pear.phar file was reported to us on 1/18 by the Paranoids FIRE Team. The last release of this file was done 12/20, so the taint occurred after that. The taint was verified by us on 1/19.
We *might* have the `` site back up by the end of this week, at least to the point where the `pear` CLI command is able to retrieve package tarballs for installation. We're at least close to that milestone in our recovery.
Very happy to say that installing/upgrading packages from the channel is working again. We are immensely grateful to everybody who has assisted getting us this far.
5/5 What we know: We cast a wide net by asking everyone to be concerned if they'd used the go-pear.phar file in the past six months. The server restoral is ongoing, by limited staff with timezone differences between the parties involved.
Workaround for installing PEAR packages while is down:
get the latest Release of the package at GitHub (e.g. ), unpack it, cd into that dir, and run `pear install package.xml` or `pear install package2.xml`.
2/5 What we know: The taint was an embedded line designed to spawn a reverse shell via Perl to IP 104.131.154.154. This IP has been reported to its host in relation to the taint.
10/10: The only community of users that likely interacted with a go-pear.phar file is someone that has PHP already and wanted to manually install PEAR themselves, and chose to manually download go-pear.phar to do it. Once PEAR is installed, go-pear.phar would not be used again.
Looking over the pear access logs today, we're getting requests via the
#pear
cli from
#php
versions lower than 5.6 - down as far as 5.1, 4.4, and 4.3. Crazy.
3/5 What we know: no other breach was identified. The install-pear-nozlib.phar was ok. The go-pear.phar file at GitHub was ok, and could be used as a good md5sum comparison for any suspect copies.
Update: the Paranoids FIRE Team has evidence to support multiple users' claims that clean files were downloaded as late as 1/15... so users can limit their own investigations to go-pear.phar receipt and usage after 1/15.
4/5 What we know: being unsure of other potential insecurities, we took the site down in order to restore a new box from backups. A previous mirror box was set to host a "PEAR is down" single info page in the meantime.
UPDATE: the peardoc section has been restored, but we now have a DB error issue with most webpages. The REST portion of the site is still good, so `pear` CLI usage can still retrieve package tarballs and information.
With in mind, we're happy to announce that the online documentation for all packages is now accessible again :-) . Thank you for your patience in letting us get this fixed.
1/10: Regarding the "six months" timeframe in the initial announcement. In addition to the report we received about go-pear.phar, we had an *indication* of unexpected iptables changes. This turned out to be security work by another group, not an attack.
7/10: If your system has PHP and PEAR preinstalled, it is hugely unlikely that go-pear.phar is on it... and even more unlikely that you would have used it on that system.
@xyahe
Correct... those contain the PEAR program itself, so go-pear.phar (one-time executable to download and install the PEAR program) is not needed, and thus not included.
4/4: Also note that this does *not* affect the PEAR installer package itself... it affects the go-pear.phar executable that you would use to initially install the PEAR installer. Using the `pear` command to install various PEAR package is *not* affected.
6/10: The largest misunderstanding we see in the wild is thinking that go-pear.phar *is* the PEAR installer program itself, and that it's what you use over and over again to install various PEAR packages. This is *not* the case.
8/10: If you installed PEAR on your Linux system using your distribution's package management tool, it is hugely unlikely that go-pear.phar was included with it... and even more unlikely that you would have used it on that system.
9/10: If you manually installed PHP and it included a PEAR installation during its installation, it is hugely unlikely that go-pear.phar was pulled in for that task (it uses install-pear-nozlib.phar instead)... and even more unlikely that you would have used it on that system.
1/4: So, if you downloaded go-pear.phar since 12/20 in order to run it once to install the PEAR package on your system, you *should* be concerned, particularly if your system has `sh` and `perl` available.
Alternatively, you could clone the GitHub repo, check out the tag of the release you want, cd and install. Generally I would advise against installing from the master/trunk branch directly... I would use the tag to get an actual released version of the code.
3/10: We can say with confidence that if you downloaded the go-pear.phar file since 12/20, **and used it to install the PEAR package installer program on your system**, then you should be *very* concerned.
@omercadocoss
Note the tweets with updates since the initial announcement. If you already used the one-use phar file, you already have the PEAR CLI command installed. There's no need to redownload go-pear.phar.
@Dave3Young
If you upgrade to 1.10.8 (released on 7th February) that XML_Util problem should go away. The Console_Getopt warning is standard and can be safely ignored.
@eric_poe
Every go-pear.phar invocation since 12/20 would have installed PEAR v1.10.7 on your system. `pear list` will show you what's on your system. However, note that v1.10.7 came out 12/5, well before go-pear.phar was tainted.
@nathanielrsuchy
Also, package managers like apt would most likely package the PEAR installer itself, rather than the go-pear.phar installation script that downloads the PEAR installer package directly. Ubuntu Disco does not package go-pear.phar --
@Dave3Young
That's finally fixed now, and documentation for all packages and versions of them have been regenerated so you shouldn't find any dead-ends from either 403s or 404s :-)
@derickr
@github
Right, because the server is not yet restored. The certificate warning is due to the "PEAR is down" page being hosted on a previous mirror. Even without the cert error, the files are unavailable for now.
@loreadi
True. Composer can install less complex pear packages into your project's vendor directory system. There are some possibly "esoteric" directives in a few packages, but for most packages it should work ok.
@omercadocoss
What you'll need to do if you think you used the one-use tainted phar file is check your system based on the date you ran the phar. The taint is a remote shell opened by the phar execution. Look for anything that shell might have done.
@phpLibHunt
Major clarifications to that article, as it seems to assume that go-pear.phar is the actual PEAR package (the command line installer). go-pear.phar is a one use installation executable to get the PEAR package itself installed.
1/4: So, if you downloaded go-pear.phar since 12/20 in order to run it once to install the PEAR package on your system, you *should* be concerned, particularly if your system has `sh` and `perl` available.
2/4: If you downloaded go-pear.phar before 12/20, we have no concrete evidence you received a tainted file... but it would be prudent to check your system if you used go-pear.phar to perform a PEAR installation in the last several months.
@TheOnlyDoo
Not sure if this is cute commentary or grand derision... I'll go with the former... at least that would make it recursive delusion if it was really the latter.
@eric_poe
This is not quite correct. If you used go-pear.phar since 12/20 to install the PEAR installer on your box, then you should be concerned that a remote shell was opened at that time. The `pear` command itself is not affected.
@Dave3Young
Sorry for the delay in replying, but I think we got that working again around the 17th. It is taking a while, but everything is slowing coming back into place - thanks for being so patient.
1/4: So, if you downloaded go-pear.phar since 12/20 in order to run it once to install the PEAR package on your system, you *should* be concerned, particularly if your system has `sh` and `perl` available.
We *might* have the `` site back up by the end of this week, at least to the point where the `pear` CLI command is able to retrieve package tarballs for installation. We're at least close to that milestone in our recovery.
@Dave3Young
Sorry - I misspoke, viewing documentation for specific packages online isn't working yet, but it is included in the package .tgz that you can now download. Apologies for getting your hopes up.
@nathanielrsuchy
I would not consider it infected. There have been no reports of other package managers (e.g. apt) indicating that they picked up a bad go-pear.phar and repackaged it into their own packages.