Category: Uncategorized

When using the zend-mail component
to send email via the ZendMailTransportSendmail 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.

The following example demonstrates injecting additional parameters to the
sendmail binary via the From address:

The attack works because zend-mail filters the email addresses using
the RFC 3696 specification,
where the string "AAA" params injection"@domain is considered a valid
address. This validation is provided using the zend-validator component with
the following parameters:

The above accepts local domain with any string specified by double quotes as the
local part. While this is valid per RFC 3696, due to the fact that sender email
addresses are provided to the sendmail binary via the command line, they create
the vulnerability described above.

Action Taken

To fix the issue, we added a transport-specific email filter for the From
header in the Sendmail transport adapter. The filter checks for the sequence" in the local part of the email From address.

ZF2016-03: Potential SQL injection in ORDER and GROUP functions of ZF1

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:

This security fix can be considered an improvement of the previousZF2016-02 andZF2014-04 advisories.

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

Action Taken

We fixed the reported SQL injection by removing comments from the SQL statement
before passing it to either the order() or group() methods; this patch
effectively solves any comment-based SQLi vectors.

This security fix can be considered as an improvement of the previousZF2014-04.

Action Taken

We fixed the reported SQL injection using two regular expressions for the order() and the group()
methods in Zend_Db_Select, created as the class constants REGEX_COLUMN_EXPR_ORDER andREGEX_COLUMN_EXPR_GROUP, respectively. These are defined as:

/^([w]+s*(([^()]|(?1))*))$/

This regexp is different from the previous REGEX_COLUMN_EXPR, which used the
character patterm [w]*; we now require at least one word boundary ([w]+).

The patch is available starting in Zend Framework 1.12.19.

Other Information

This SQL injection attack does not affect Zend Framework 2 and 3 versions because the
implementations of ZendDbSqlSelect::order() and ZendDbSqlSelect::group() do
not manage parenthetical expressions.

Acknowledgments

The Zend Framework team thanks the following for identifying the issues and
working with us to help protect its users:

ZF2016-01: Potential Insufficient Entropy Vulnerability in ZF1

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.

Action Taken

We replaced the usage of rand() and mt_rand() with the random generators of
ZF1 implemented in Zend_Crypt_Math().

Moreover, we removed the usage of openssl_random_pseudo_bytes() functions inZend_Crypt_Math::randBytes(). This removal is not a BC break for Linux users
thanks to the usage of /dev/urandom as an entropy source. For Windows users,
this can be a BC break if the Mcrypt extension is not enabled.

The following releases contain the fixes:

Zend Framework 1.12.18

Recommendations

If you are using an affected version of PHP, we highly recommend upgrading
immediately to Zend Framework 1.12.18.

Other Information

Acknowledgments

The Zend Framework team thanks the following for identifying the issues and
working with us to help protect its users:

Brian Engert of Soliant Consulting, who
discovered, reported, and proposed a patch for the issue;

Enrico Zimuel, who tested the patch and added the patch
for the OpenSSL usage removal.

ZendCryptPublicKeyRsaPublicKey has a call to openssl_public_encrypt()
which uses PHP’s default $padding argument, which specifiesOPENSSL_PKCS1_PADDING, indicating usage of PKCS1v1.5 padding. This padding has
a known vulnerability, the Bleichenbacher’s chosen-ciphertext attack,
which can be used to decrypt arbitrary ciphertexts.

Action Taken

ZendCryptPublicKeyRsaPublicKey::encrypt() was updated to accept an
additional argument, $padding; the default value for this argument was set
to OPENSSL_PKCS1_OAEP_PADDING.

ZendCryptPublicKeyRsaPrivateKey::decrypt() was updated to accept an
additional argument, $padding; the default value for this argument was set
to OPENSSL_PKCS1_OAEP_PADDING.

ZendCryptPublicKeyRsa::encrypt() was updated to accept an additional
optional argument, $padding, allowing the user to specify the padding to use
with PublicKey::encrypt().

ZendCryptPublicKeyRsa::decrypt() was updated to accept an additional
optional argument, $padding, allowing the user to specify the padding to use
with PrivateKey::decrypt().

The above changes represent a backwards-compatibility break, but were necessary
to prevent the outlined vulnerability. If you were usingZendCryptPublicKeyRsa previously, you will likely need to re-encrypt any
data you’ve previously encrypted to use the new padding. This can be done as
follows:

In Zend Framework, Zend_Captcha_Word (v1) and ZendCaptchaWord (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.

Action Taken

The code used to randomly select letters was updated as follows:

In Zend Framework 1.12.17, the methods randBytes() and randInteger() were
added to Zend_Crypt_Math. Zend_Captcha_AbstractWord was updated to useZend_Crypt_Math::randInteger() instead of array_rand() when selecting
letters for the CAPTCHA word.

In the package zendframework/zend-captcha 2.4.9/2.5.2 and Zend Framework
2.4.9, ZendCaptchaAbstractWord was updated to useZendMathRand::getInteger() instead of array_rand() when selecting
letters for the CAPTCHA word.

The following releases contain the fixes:

Zend Framework 1.12.17

Zend Framework 2.4.9

zend-captcha 2.4.9

zend-captcha 2.5.2

Recommendations

This patch is considered a security hardening patch, and as such, was not
assigned a CVE identifier.

Regardless, if you use one of the word-based CAPTCHA adapters in Zend Framework
1 or 2, we recommend upgrading to 1.12.17, 2.4.9, or zend-captcha 2.4.9/2.5.2.

Other Information

Acknowledgments

The Zend Framework team thanks the following for identifying the issues and
working with us to help protect its users:

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.

Action Taken

We added null byte filtering in the PDO abstract componentZend_Db_Adapter_Pdo_Abstract. We decided to use the abstract component to
prevent null byte injection in all the PDO adapters once we discovered the
situation was not specific to pdo_dblib.

We used the PHP’s addcslashes to sanitize and properly quote null bytes:

$value = addcslashes($value, "{$content}02");

The following releases contain the fixes:

Zend Framework 1.12.16

Recommendations

If you use one of the PDO-based adapters in Zend Framework 1, we recommend
upgrading to 1.12.16 immediately.

Other Information

Acknowledgments

The Zend Framework team thanks the following for identifying the issues and
working with us to help protect its users:

Chris Kings-Lynne, who discovered and reported the issue against theZend_Db_Adapter_Pdo_Mssql component of ZF1;