CVE-2015-5161

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.

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.

The Zend_Xml_Security::scan in ZendXml before 1.0.1 and Zend Framework before 1.12.14, 2.x before 2.4.6, and 2.5.x before 2.5.2, when running under PHP-FPM in a threaded environment, allows remote attackers to bypass security checks and conduct XML external entity (XXE) and XML entity expansion (XEE) attacks via multibyte encoded characters.

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.

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-p1+tuxcare.

TuxCare rebuilt zendframework/zendframework1 to address 12 CVEs. Fixed in 1.11.0-p1+tuxcare.

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

The Zend_Xml_Security::scan in ZendXml before 1.0.1 and Zend Framework before 1.12.14, 2.x before 2.4.6, and 2.5.x before 2.5.2, when running under PHP-FPM in a threaded environment, allows remote attackers to bypass security checks and conduct XML external entity (XXE) and XML entity expansion (XEE) attacks via multibyte encoded characters.

Updated php-ZendFramework packages fix security vulnerability:

Dawid Golunski discovered that when running under PHP-FPM in a threaded environment, Zend Framework, a PHP framework, did not properly handle XML data in multibyte encoding. This could be used by remote attackers to perform an XML External Entity attack via crafted XML data (CVE-2015-5161).

Updated php-ZendFramework and php-ZendFramework2 packages fix security vulnerability:

Dawid Golunski discovered that when running under PHP-FPM in a threaded environment, Zend Framework, a PHP framework, did not properly handle XML data in multibyte encoding. This could be used by remote attackers to perform an XML External Entity attack via crafted XML data (CVE-2015-5161).

This update for php53 to version 5.3.17 fixes the following issues:

These security issues were fixed:

• CVE-2016-5093: get_icu_value_internal out-of-bounds read (bnc#982010).
• CVE-2016-5094: Don't create strings with lengths outside int range (bnc#982011).
• CVE-2016-5095: Don't create strings with lengths outside int range (bnc#982012).
• CVE-2016-5096: int/size_t confusion in fread (bsc#982013).
• CVE-2016-5114: fpm_log.c memory leak and buffer overflow (bnc#982162).
• CVE-2015-8879: The odbc_bindcols function in ext/odbc/php_odbc.c in PHP mishandles driver behavior for SQL_WVARCHAR columns, which allowed remote attackers to cause a denial of service (application crash) in opportunistic circumstances by leveraging use of the odbc_fetch_array function to access a certain type of Microsoft SQL Server table (bsc#981050).
• CVE-2015-4116: Use-after-free vulnerability in the spl_ptr_heap_insert function in ext/spl/spl_heap.c in PHP allowed remote attackers to execute arbitrary code by triggering a failed SplMinHeap::compare operation (bsc#980366).
• CVE-2015-8874: Stack consumption vulnerability in GD in PHP allowed remote attackers to cause a denial of service via a crafted imagefilltoborder call (bsc#980375).
• CVE-2015-8873: Stack consumption vulnerability in Zend/zend_exceptions.c in PHP allowed remote attackers to cause a denial of service (segmentation fault) via recursive method calls (bsc#980373).
• CVE-2016-4540: The grapheme_stripos function in ext/intl/grapheme/grapheme_string.c in PHP allowed remote attackers to cause a denial of service (out-of-bounds read) or possibly have unspecified other impact via a negative offset (bsc#978829).
• CVE-2016-4541: The grapheme_strpos function in ext/intl/grapheme/grapheme_string.c in PHP allowed remote attackers to cause a denial of service (out-of-bounds read) or possibly have unspecified other impact via a negative offset (bsc#978829.
• CVE-2016-4542: The exif_process_IFD_TAG function in ext/exif/exif.c in PHP did not properly construct spprintf arguments, which allowed remote attackers to cause a denial of service (out-of-bounds read) or possibly have unspecified other impact via crafted header data (bsc#978830).
• CVE-2016-4543: The exif_process_IFD_in_JPEG function in ext/exif/exif.c in PHP did not validate IFD sizes, which allowed remote attackers to cause a denial of service (out-of-bounds read) or possibly have unspecified other impact via crafted header data (bsc#978830.
• CVE-2016-4544: The exif_process_TIFF_in_JPEG function in ext/exif/exif.c in PHP did not validate TIFF start data, which allowed remote attackers to cause a denial of service (out-of-bounds read) or possibly have unspecified other impact via crafted header data (bsc#978830.
• CVE-2016-4537: The bcpowmod function in ext/bcmath/bcmath.c in PHP accepted a negative integer for the scale argument, which allowed remote attackers to cause a denial of service or possibly have unspecified other impact via a crafted call (bsc#978827).
• CVE-2016-4538: The bcpowmod function in ext/bcmath/bcmath.c in PHP modified certain data structures without considering whether they are copies of the zero, one, or two global variable, which allowed remote attackers to cause a denial of service or possibly have unspecified other impact via a crafted call (bsc#978827).
• CVE-2016-4539: The xml_parse_into_struct function in ext/xml/xml.c in PHP allowed remote attackers to cause a denial of service (buffer under-read and segmentation fault) or possibly have unspecified other impact via crafted XML data in the second argument, leading to a parser level of zero (bsc#978828).
• CVE-2016-4342: ext/phar/phar_object.c in PHP mishandles zero-length uncompressed data, which allowed remote attackers to cause a denial of service (heap memory corruption) or possibly have unspecified other impact via a crafted (1) TAR, (2) ZIP, or (3) PHAR archive (bsc#977991).
• CVE-2016-4346: Integer overflow in the str_pad function in…