Supply chain flaws in PHP PEAR package manager went undiscovered for 15 years

0

Adam Bannister Apr 04, 2022 15:30 UTC

Updated: April 05, 2022 09:14 UTC

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

UPDATE According to security researchers, the attackers could have wreaked havoc on the PHP ecosystem by exploiting a pair of long-standing vulnerabilities that were only recently patched in the PEAR package manager.

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

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

The defects remained unknown for more than 15 years. Chauchefoin says The daily sip that the fact that researchers, not attackers, discovered the flaws was “a happy escape”, given that “a compromise of the PEAR repository would have allowed attackers to hijack any package hosted on the platform ” and publish malicious versions.

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

“Minimal technical expertise”

PEAR has fallen out of favor amid the rise of rival PHP package manager Composer, in whose main repository SonarSource revealed an equally serious vulnerability last year.

CONTEXT PHP Package Manager Flaw Left Millions of Web Applications Open to Abuse

However, PEAR is still widely used, with the Net_SMTP and Mail packages alone seeing 100,000 downloads per 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 significant disruptions and security breaches across the globe,” according to Chauchefoin.

Low PRNG

PEAR’s password reset function used to generate random values, even though the technique is outdated and inappropriate to generate cryptographically secure values.

After the values ​​are concatenated and hashed with , “the final value is only based on two unknowns, which are the output of and,” Chauchefoin said.

“The first can’t give many values ​​(10), and the second can easily be approximated by the attacker. Also, pear.php.net’s HTTP server adds a Date header to its responses, reducing it to only a few values ​​(

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

Learn about the latest news on software supply chain attacks

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

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

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

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

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

too much confidence

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

The persistence of PEAR flaws for so many years shows how well-resourced companies that rely on package managers are not doing enough to secure them. “Package manager backend services receive little attention from security contributors, despite being a central part of every language’s ecosystem,” explains the researcher.

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

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

YOU MIGHT ALSO LIKE GitLab fixes a critical account takeover bug

Share.

Comments are closed.