Affected are PHP-based websites running a vulnerable version of the web application development tool Zend Framework, as well as certain Laminas Project releases.
An attacker can exploit versions of the popular developer tool Zend Framework and its successor Laminas Project to execute remote code on PHP-based websites running web applications that are vulnerable to attack.
However, those who maintain Zend Framework emphasize that “inherently insecure” code must be written by the application author before a web application can be exploited. Therefore, the current Zend Framework maintainers dispute whether or not the vulnerability classification is accurate.
“We contest the vulnerability and consider our patch to be a security tightening patch, not a vulnerability patch,” said Zend product owner and principal engineer Matthew Weier O’Phinney in an email interview with us.
Versions of the Zend Framework Affected
Impacted are Zend Framework version 3.0.0 and Laminas Project laminas-HTTP versions before 2.14.2, with an estimated “multiple million” websites using the framework potentially affected. The new maintainers of Zend Framework, Laminas Project, are part of the open-source collaborative ecosystem of the Linux Foundation.
Monday, security researcher Ling Yizhou disclosed the vulnerability to the public and published two proof-of-concept attack scenarios. MITRE does not list a severity rating for the flaw with the identifier CVE-2021-3007. Others within the cybersecurity community, however, deem it to be “high risk.”
After Zend Framework’s support ended on December 31, 2019, it was merged into the Laminas Project. Zend Framework and Laminas Project are equivalent, according to their respective maintainers.
“The project consists of distinct, independently-versioned components. Therefore, “3.0” refers to a handful of core components that were labeled with version 3 releases, the majority of which have evolved significantly since then,” O’Phinney explained to us.
The Deserialization Flaw and Proof-of-Concept Attack Scenarios
According to Yizhou, Zend Framework 3.0.0 contains a deserialization flaw that can result in remote code execution “if the content is controllable and is related to the __destruct method of the ZendHttpResponseStream class in Stream.php.”
Yizhou, a security researcher, published proof-of-concept (PoC) attack scenarios against Zend Framework and Laminas Project on a GitHub page he manages. Additional mitigation information can be found on the Lamina Project’s GitHub page.
A deserialization (also known as insecure deserialization) vulnerability occurs when a website deserializes user-controllable data. In other words, when a website permits a user to inject untrusted data or an object into a web application. As the data is deserialized, the injected data can exploit the logic of an application to launch a denial-of-service (DoS) attack or allow an attacker to execute arbitrary code.
Deserialization and serialization are technical terms that describe the transformation of an object (code) into a reversible data format (serialization) (deserialization). People serialize objects to save them for storage or send them as part of communications, according to OWASP.
The vulnerability is related to the “__destruct method” within the “HttpResponseStream class in Stream.php” of the Zend Framework.
Controversial “Vulnerability” Classification
The Laminas Project of the Linux Foundation contests the CVE classification. It stated in a statement posted to its GitHub page:
“Upon review, we’ve determined that this is not a framework-specific vulnerability, but rather a language-wide issue. The un/serialize() functions have a lengthy history of vulnerabilities (see https://www.google.com/search?q=php+unserialize+RCE for more information). , and developers should NEVER use it with untrusted input. If this is not possible, they should pass the second ‘$options’ argument and provide a list of allowed classes, or use the argument to disallow all object unserialization (see https://www.php.net/unserialize for details).
We also received the report against Zend Framework that you provided. This project is no longer active, and any security issues with the Laminas Project have been resolved (which will require users to migrate to Laminas from ZF). Our findings for that project remain unchanged; this is a PHP language issue, not a problem specific to our project.”
It was also stated that the classification is generally understood as “PHP Object Injection” and is not framework-specific.
“However, we’re providing this patch to further protect our users against these scenarios. In the LaminasHttpResponseStream destructor, 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 object’s __toString() method).
