CVE-2014-2683

In Zend Framework, Zend_Captcha_Word (v1) and Zend\Captcha\Word (v2) generate a "word" for a CAPTCHA challenge by selecting a sequence of random letters from a character set. Prior to this advisory, the selection was performed using PHP's internal array_rand() function. This function does not generate sufficient entropy due to its usage of rand() instead of more cryptographically secure methods such as openssl_pseudo_random_bytes(). This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.

We discovered several methods used to generate random numbers in ZF1 that potentially used insufficient entropy. These random number generators are used in the following method calls:

Zend_Ldap_Attribute::createPassword
Zend_Form_Element_Hash::_generateHash
Zend_Gdata_HttpClient::filterHttpRequest
Zend_Filter_Encrypt_Mcrypt::_srand
Zend_OpenId::randomBytes

In each case, the methods were using rand() or mt_rand(), neither of which can generate cryptographically secure values. This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.

Moreover, we discovered a potential security issue in the usage of the openssl_random_pseudo_bytes() function in Zend_Crypt_Math::randBytes, reported in PHP BUG #70014, and the security implications reported in a discussion on the random_compat library.

Using the Consumer component of ZendOpenId (or Zend_OpenId in ZF1), it is possible to login using an arbitrary OpenID account (without knowing any secret information) by using a malicious OpenID Provider. That means OpenID it is possible to login using arbitrary OpenID Identity (MyOpenID, Google, etc), which are not under the control of our own OpenID Provider. Thus, we are able to impersonate any OpenID Identity against the framework.

Moreover, the Consumer accepts OpenID tokens with arbitrary signed elements. The framework does not check if, for example, both openid.claimed_id and openid.endpoint_url are signed. It is just sufficient to sign one parameter. According to https://openid.net/specs/openid-authentication-2_0.html#positive_assertions, at least op_endpoint, return_to, response_nonce, assoc_handle, and, if present in the response, claimed_id and identity, must be signed.

The default error handling view script generated using Zend_Tool failed to escape request parameters when run in the "development" configuration environment, providing a potential XSS attack vector.

Zend_Tool_Project_Context_Zf_ViewScriptFile was patched such that the view script template now calls the escape() method on dumped request variables.

Zend Framework 1.11.4 includes a patch that adds escaping to the generated error/error.phtml view script, ensuring that request variables are escaped appropriately for the browser. Do note, however, that this will not update any previously generated code. You will still need to follow the next advice for previously generated error view scripts.

When using the zend-mail component to send email via the Zend\Mail\Transport\Sendmail transport, a malicious user may be able to inject arbitrary parameters to the system sendmail program. The attack is performed by providing additional quote characters within an address; when unsanitized, they can be interpreted as additional command line arguments, leading to the vulnerability.

Numerous components utilizing PHP's DOMDocument, SimpleXML, and xml_parse functionality are vulnerable to two types of attacks:

• XML eXternal Entity (XXE) Injection attacks. The above mentioned extensions are insecure by default, allowing external entities to be specified by adding a specific DOCTYPE element to XML documents and strings. By exploiting this vulnerability an application may be coerced to open arbitrary files and/or TCP connections.
• XML Entity Expansion (XEE) vectors, leading to Denial of Service vectors. XEE attacks occur when the XML DOCTYPE declaration includes XML entity definitions that contain either recursive or circular references; this leads to CPU and memory consumption, making Denial of Service exploits trivial to implement.

The PDO adapters of Zend Framework 1 do not filter null bytes values in SQL statements. A PDO adapter can treat null bytes in a query as a string terminator, allowing an attacker to add arbitrary SQL following a null byte, and thus create a SQL injection.

We tested and verified the null byte injection using pdo_dblib (FreeTDS) on a Linux environment to access a remote Microsoft SQL Server, and also tested against and noted the vector against pdo_sqlite.

Zend Framework 1 (ZF1) before 1.12.4, Zend Framework 2 before 2.1.6 and 2.2.x before 2.2.6, ZendOpenId, ZendRest, ZendService_AudioScrobbler, ZendService_Nirvanix, ZendService_SlideShare, ZendService_Technorati, and ZendService_WindowsAzure before 2.0.2, ZendService_Amazon before 2.0.3, and ZendService_Api before 1.0.0 allow remote attackers to cause a denial of service (CPU consumption) via (1) recursive or (2) circular references in an XML entity definition in an XML DOCTYPE declaration, aka an XML Entity Expansion (XEE) attack. NOTE: this issue exists because of an incomplete fix for CVE-2012-6532.

Zend_XmlRpc is vulnerable to XML eXternal Entity (XXE) Injection attacks. The SimpleXMLElement class (SimpleXML PHP extension) is used in an insecure way to parse XML data. External entities can be specified by adding a specific DOCTYPE element to XML-RPC requests. By exploiting this vulnerability an application may be coerced to open arbitrary files and/or TCP connections.

The implementation of the ORDER BY SQL statement in Zend_Db_Select of Zend Framework 1 contains a potential SQL injection when the query string passed contains parentheses.

For instance, the following code is affected by this issue:

$db     = Zend_Db::factory( /* options here */ );
$select = $db->select()
    ->from(array('p' => 'products'))
    ->order('MD5(1); drop table products');
echo $select;

This code produce the string:

SELECT "p".* FROM "products" AS "p" ORDER BY MD5(1);drop table products ASC

instead of the correct one:

SELECT "p".* FROM "products" AS "p" ORDER BY "MD5(1);drop table products" ASC

The SQL injection occurs because we create a new Zend_Db_Expr() object, in presence of parentheses, passing directly the value without any filter on the string.

The implementation of ORDER BY and GROUP BY in Zend_Db_Select remained prone to SQL injection when a combination of SQL expressions and comments were used. This security patch provides a comprehensive solution that identifies and removes comments prior to checking validity of the statement to ensure no SQLi vectors occur.

The implementation of ORDER BY and GROUP BY in Zend_Db_Select of ZF1 is vulnerable by the following SQL injection:

$db = Zend_Db::factory(/* options here */);
$select = new Zend_Db_Select($db);
$select->from('p');
$select->order("MD5(\"a(\");DELETE FROM p2; #)"); // same with group()

The above $select will render the following SQL statement:

SELECT `p`.* FROM `p` ORDER BY MD5("a(");DELETE FROM p2; #) ASC

instead of the correct one:

SELECT "p".* FROM "p" ORDER BY "MD5(""a("");DELETE FROM p2; #)" ASC

This security fix can be considered an improvement of the previous ZF2016-02 and ZF2014-04 advisories.

As a final consideration, we recommend developers either never use user input for these operations, or filter user input thoroughly prior to invoking Zend_Db. You can use the Zend_Db_Select::quoteInto() method to filter the input data, as shown in this example:

$db    = Zend_Db::factory(...);
$input = "MD5(\"a(\");DELETE FROM p2; #)"; // user input can be an attack
$order = $db->quoteInto("SQL statement for ORDER", $input);

$select = new Zend_Db_Select($db);
$select->from('p');
$select->order($order); // same with group()

In Zend Framework, Zend_Captcha_Word (v1) and Zend\Captcha\Word (v2) generate a "word" for a CAPTCHA challenge by selecting a sequence of random letters from a character set. Prior to this advisory, the selection was performed using PHP's internal array_rand() function. This function does not generate sufficient entropy due to its usage of rand() instead of more cryptographically secure methods such as openssl_pseudo_random_bytes(). This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.

We discovered several methods used to generate random numbers in ZF1 that potentially used insufficient entropy. These random number generators are used in the following method calls:

Zend_Ldap_Attribute::createPassword
Zend_Form_Element_Hash::_generateHash
Zend_Gdata_HttpClient::filterHttpRequest
Zend_Filter_Encrypt_Mcrypt::_srand
Zend_OpenId::randomBytes

In each case, the methods were using rand() or mt_rand(), neither of which can generate cryptographically secure values. This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.

Moreover, we discovered a potential security issue in the usage of the openssl_random_pseudo_bytes() function in Zend_Crypt_Math::randBytes, reported in PHP BUG #70014, and the security implications reported in a discussion on the random_compat library.

Using the Consumer component of ZendOpenId (or Zend_OpenId in ZF1), it is possible to login using an arbitrary OpenID account (without knowing any secret information) by using a malicious OpenID Provider. That means OpenID it is possible to login using arbitrary OpenID Identity (MyOpenID, Google, etc), which are not under the control of our own OpenID Provider. Thus, we are able to impersonate any OpenID Identity against the framework.

Moreover, the Consumer accepts OpenID tokens with arbitrary signed elements. The framework does not check if, for example, both openid.claimed_id and openid.endpoint_url are signed. It is just sufficient to sign one parameter. According to https://openid.net/specs/openid-authentication-2_0.html#positive_assertions, at least op_endpoint, return_to, response_nonce, assoc_handle, and, if present in the response, claimed_id and identity, must be signed.

The default error handling view script generated using Zend_Tool failed to escape request parameters when run in the "development" configuration environment, providing a potential XSS attack vector.

Zend_Tool_Project_Context_Zf_ViewScriptFile was patched such that the view script template now calls the escape() method on dumped request variables.

Zend Framework 1.11.4 includes a patch that adds escaping to the generated error/error.phtml view script, ensuring that request variables are escaped appropriately for the browser. Do note, however, that this will not update any previously generated code. You will still need to follow the next advice for previously generated error view scripts.

When using the zend-mail component to send email via the Zend\Mail\Transport\Sendmail transport, a malicious user may be able to inject arbitrary parameters to the system sendmail program. The attack is performed by providing additional quote characters within an address; when unsanitized, they can be interpreted as additional command line arguments, leading to the vulnerability.

Numerous components utilizing PHP's DOMDocument, SimpleXML, and xml_parse functionality are vulnerable to two types of attacks:

• XML eXternal Entity (XXE) Injection attacks. The above mentioned extensions are insecure by default, allowing external entities to be specified by adding a specific DOCTYPE element to XML documents and strings. By exploiting this vulnerability an application may be coerced to open arbitrary files and/or TCP connections.
• XML Entity Expansion (XEE) vectors, leading to Denial of Service vectors. XEE attacks occur when the XML DOCTYPE declaration includes XML entity definitions that contain either recursive or circular references; this leads to CPU and memory consumption, making Denial of Service exploits trivial to implement.

The PDO adapters of Zend Framework 1 do not filter null bytes values in SQL statements. A PDO adapter can treat null bytes in a query as a string terminator, allowing an attacker to add arbitrary SQL following a null byte, and thus create a SQL injection.

We tested and verified the null byte injection using pdo_dblib (FreeTDS) on a Linux environment to access a remote Microsoft SQL Server, and also tested against and noted the vector against pdo_sqlite.

TuxCare rebuilt zendframework/zendframework1 to address 7 CVEs. Fixed in 1.12.10-p2+tuxcare.

TuxCare rebuilt zendframework/zendframework1 to address 23 CVEs. Fixed in 1.10.6-p1+tuxcare.

TuxCare rebuilt zendframework/zendframework1 to address 6 CVEs. Fixed in 1.11.0-p4+tuxcare.

Zend Framework 1 (ZF1) before 1.12.4, Zend Framework 2 before 2.1.6 and 2.2.x before 2.2.6, ZendOpenId, ZendRest, ZendService_AudioScrobbler, ZendService_Nirvanix, ZendService_SlideShare, ZendService_Technorati, and ZendService_WindowsAzure before 2.0.2, ZendService_Amazon before 2.0.3, and ZendService_Api before 1.0.0 allow remote attackers to cause a denial of service (CPU consumption) via (1) recursive or (2) circular references in an XML entity definition in an XML DOCTYPE declaration, aka an XML Entity Expansion (XEE) attack. NOTE: this issue exists because of an incomplete fix for CVE-2012-6532.

Updated php-ZendFramework packages fix security vulnerabilities:

XML eXternal Entity (XXE) and XML Entity Expansion (XEE) flaws were discovered in the Zend Framework. An attacker could use these flaws to cause a denial of service, access files accessible to the server process, or possibly perform other more advanced XML External Entity (XXE) attacks (CVE-2014-2681, CVE-2014-2682, CVE-2014-2683).

Using the Consumer component of Zend_OpenId, it is possible to login using an arbitrary OpenID account (without knowing any secret information) by using a malicious OpenID Provider. That means OpenID it is possible to login using arbitrary OpenID Identity (MyOpenID, Google, etc), which are not under the control of our own OpenID Provider. Thus, we are able to impersonate any OpenID Identity against the framework (CVE-2014-2684, CVE-2014-2685).