Versions of the popular developer tool Zend Framework and its successor Laminas Project can be abused by an attacker to execute remote code on PHP-based websites, if they are running web-based applications that are vulnerable to attack.
However, those that maintain Zend Framework emphasize that the conditions under which a web app can be abused first require the application author to write code that is “inherently insecure.” For that reason, the current maintainers of Zend Framework are contesting whether or not the vulnerability classification is correct.
“We are contesting the vulnerability, and consider our patch a security tightening patch, and not a vulnerability patch,” said Matthew Weier O’Phinney, Zend product owner and principal engineer in an email-based interview with Threatpost.
Impacted Versions of Zend Framework
Impacted is Zend Framework version 3.0.0 and Laminas Project laminas-http before 2.14.2, with an estimated “several million websites” using the framework and possibly impacted. The new maintainers of Zend Framework, Laminas Project, fall within the Linux Foundation’s open-source collaborative ecosystem.
The bug was publicly disclosed Monday by cybersecurity researcher Ling Yizhou, who also published two proof-of-concept attack scenarios. The bug, tracked as CVE-2021-3007, does not have a severity rating listed with MITRE. However it is rated “high risk” by others within the cybersecurity community.
End of life for Zend Framework was Dec. 31, 2019, after which it was folded into the Laminas Project. According to the maintainers, Zend Framework and Laminas Project are equivalent.
“The project is a collection of individual components, each versioned separately. As such, ‘3.0’ refers to a handful of core components that were tagged with version 3 releases, many of which have evolved significantly from then,” O’Phinney told Threatpost.
The Deserialization Vulnerability and PoC Attack Scenarios
According to Yizhou, the Zend Framework 3.0.0 version has a deserialization vulnerability that can lead to remote code execution “if the content is controllable, related to the __destruct method of the Zend\Http\Response\Stream class in Stream.php.”
Proof-of-concept (PoC) attack scenarios against Zend Framework and Laminas Project were posted a GitHub page maintained by security researcher Yizhou. Additional mitigation details are located at the Lamina Project page, also hosted on GitHub.
A deserialization (A.K.A. insecure deserialization) vulnerability is when user-controllable data is deserialized by a website. In other words, when a website allows a user to introduce untrusted data, or perform an object injection, into a web app. The injected data can abuse the logic of an application and trigger a denial-of-service (DoS) attack or allow an attacker to execute arbitrary code as the data is deserialized.
Deserialization and serialization are tech terms describing the process of turning some object (code) into a data format (serialization) that can be restored later (deserialization). “People often serialize objects in order to save them to storage, or to send as part of communications,” OWASP describes.
The vulnerability is related to the” __destruct method” within the Zend Framework’s “\Http\Response\Stream class in Stream.php.”
Disputed “Vulnerability” Classification
The Linux Foundation’s Laminas Project is disputing the CVE classification. In a statement posted to its GitHub page, it stated:
“On review, we feel this is not a vulnerability specific to the framework, but rather more generally to the language. The un/serialize() functions have a long history of vulnerabilities (please see https://www.google.com/search?q=php+unserialize+RCE for example), and developers should NEVER use it on untrusted input. If this is impossible, they should at the very least pass the second `$options` argument, and provide a list of allowed classes, or use the argument to disallow all unserialization of objects (see https://www.php.net/unserialize for details).
We also received the report you provided against Zend Framework. That project is no longer active, and any security issues are now resolved in the Laminas Project (which will require users migrate to Laminas from ZF). Our findings remain the same for that project, however; this is a PHP language issue, and not specific to our project.”
It further stated that the classification is more generally understood as a “PHP Object Injection” and not specific to any given framework.
“Regardless, we are providing this patch to help further protect our users from these scenarios. The patch provides type checking of the $streamName property before performing a cleanup operation (which results in an unlink() operation, which, previously, could have resulted in an implied call to an an object’s __toString() method) in the Laminas\Http\Response\Stream destructor,” the message read.
Supply-Chain Security: A 10-Point Audit Webinar: Is your company’s software supply-chain prepared for an attack? On Wed., Jan. 20 at 2p.m. ET, start identifying weaknesses in your supply-chain with actionable advice from experts – part of a limited-engagement and LIVE Threatpost webinar. CISOs, AppDev and SysAdmin are invited to ask a panel of A-list cybersecurity experts how they can avoid being caught exposed in a post-SolarWinds-hack world. Attendance is limited: Register Now and reserve a spot for this exclusive Threatpost Supply-Chain Security webinar – Jan. 20, 2 p.m. ET.
