PEAR was ripe for exploitation via cryptographic flaw and bug in outdated dependency

Severe supply chain flaws in PHP package manager PEAR lay undiscovered for 15 years

UPDATED Attackers could have wreaked havoc on the PHP ecosystem by exploiting a pair of longstanding vulnerabilities that were only recently patched in package manager PEAR, according to security researchers.

PEAR developer accounts were left at risk of malicious takeover by a flaw arising from weak entropy on the password reset function, revealed Thomas Chauchefoin, a vulnerability researcher at Swiss security firm SonarSource, in a blog post.

Attackers could then secure persistent access to the central PEAR server via abuse of a separate vulnerability in an outdated version of a bundled dependency.

The flaws lay undiscovered for more than 15 years. Chauchefoin told The Daily Swig that the fact researchers, and not attackers, discovered the flaws was “a lucky escape”, given “a compromise of the PEAR repository would have allowed attackers to hijack any package hosted on the platform” and publish malicious releases.

SonarSource has published a video explaining the two-pronged attack scenario.



‘Minimal technical expertise’

PEAR has fallen out of favor amid the rise to dominance of rival PHP package manager Composer, in whose principal repository SonarSource disclosed a similarly serious vulnerability last year.


BACKGROUND PHP package manager flaw left millions of web apps open to abuse


However, PEAR is still widely used, with the Net_SMTP and Mail packages alone racking up 100,000 downloads a month via the PHP installer.

The supply chain vulnerabilities “could have been easily identified and exploited by threat actors with only minimal technical expertise, causing important disruption and security breaches across the world”, according to Chauchefoin.

Weak PRNG

PEAR’s password reset function used mt_rand() to generate random values, even though the technique is obsolete and unsuitable for generating cryptographically secure values.

Once the values were concatenated and hashed with md5(), “the final value is only based on two unknowns, which are the output of mt_rand() and time(),” said Chauchefoin.

“The first one cannot yield many values (10), and the second one can easily be approximated by the attacker. In addition, the HTTP server of pear.php.net adds a Date header to its responses, narrowing it down to only a few values (< 5).”

The researchers concluded that attackers could secure a valid password reset token within 50 attempts.


Read more of the latest software supply chain attack news


The other bug provided a backdoor for continuing attacks even if the first bug had been fixed. “It could also help them to hide their tracks by modifying access logs,” said Chauchefoin.

The flaw arose because pearweb pulled version 1.4.7 of Archive_Tar, which was vulnerable to CVE-2020-36193, a directory traversal issue that could lead to remote code execution (RCE) on PEAR.

SonarSource warned the maintainers of PEAR about the bugs on July 30, 2021.

They were patched in pearweb version 1.32, released on March 13, with all previous versions affected.

However, Chauchefoin advised PEAR users to “consider migrating to Composer, where the contributors community is more active and the same packages are available”.

Too much trust

Software supply chain attacks targeting PEAR and similar developer tools have a particularly significant impact given developers often run them on their computers before deploying to production servers, “creating an opportunity for attackers to pivot into companies’ internal networks”, Chauchefoin said.

The PEAR flaws’ persistence over so many years highlights how well-resourced companies that rely on package managers don't do enough to secure them. “The backend services of package managers get only little attention from security contributors, while they are a central component of every language’s ecosystem,” the researcher explained.

Citing comparable flaws found in Composer, CocoaPods, and RubyGems, Chauchefoin warns that “similar vulnerabilities will be found again, so it is very important to try to reduce their impact by removing the trust we put in the backend services; initiatives like sigstore are a good answer to that and we should push for their adoption”.


This article was updated on April 5 with additional comment from SonarSource.


YOU MIGHT ALSO LIKE GitLab addresses critical account hijack bug