#php

The call for papers for Hardwear.io 2024 in the Netherlands is now open. It will take place October 24th through the 24th, 2024 at the Marriott Hotel, Amsterdam, The Netherlands.

Details have emerged about a new critical security flaw impacting PHP that could be exploited to achieve remote code execution under certain circumstances. The vulnerability, tracked as CVE-2024-4577, has been described as a CGI argument injection vulnerability affecting all versions of PHP installed on the Windows operating system. According to DEVCORE security researcher, the shortcoming makes

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 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 deve...

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()](http://php.net/manual/en/function.openssl-random-pseudo-bytes.php) function in Zend_Crypt_Math::randBytes, reported in PHP BUG [#70014](https://bugs.php.net/bug.php?id=70014), and the security implications reported in a discussion [on the random_compat library.](https://github.com/...

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.

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.

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.

A regex expression in ua-parser/uap-php could lead to a ReDoS vulnerability in versions prior to 3.8.0.