Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend
Framework, please report it to us at zf-security@zend.com. We will
work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

Component(s) affected

A description indicating how to reproduce the issue

A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the
project contributors a chance to resolve the vulnerability and issue a new
release prior to any public exposure; this helps protect Zend Framework
users and provides them with a chance to upgrade and/or update in order to
protect their applications.

Policy

We will patch the current release branch, as well as the immediate prior
minor release branch.

After patching the release branches, we will immediately issue new
security fix releases for each patched release branch.

A security advisory will be released on the Zend Framework site
detailing the vulnerability, as well as recommendations for end-users to
protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as
via a feed (which is also present in the
website head for easy feed discovery)

Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend
Framework, please report it to us at zf-security@zend.com. We will
work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

Component(s) affected

A description indicating how to reproduce the issue

A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the
project contributors a chance to resolve the vulnerability and issue a new
release prior to any public exposure; this helps protect Zend Framework
users and provides them with a chance to upgrade and/or update in order to
protect their applications.

Policy

We will patch the current release branch, as well as the immediate prior
minor release branch.

After patching the release branches, we will immediately issue new
security fix releases for each patched release branch.

A security advisory will be released on the Zend Framework site
detailing the vulnerability, as well as recommendations for end-users to
protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as
via a feed (which is also present in the
website head for easy feed discovery)

The implication is that subsequent calls to Zend\Session\SessionManager#start()
(in later requests, assuming a session was created) will not have
any validator metadata attached, which causes any validator metadata
to be re-built from scratch, thus marking the session as valid.

An attacker is thus able to simply ignore session validators
such as RemoteAddr or HttpUserAgent, since the "signature" that
these validators check against is not being stored in the session.

Action Taken

We now store the signature of the validators in the session immediately following
the call to session_start, preventing any data loss from session
validators.

The patch fixing the issue has been applied in the following versions:

Zend Framework 2.2.9

Zend Framework 2.3.4

Recommendations

If you are using session validators, we recommend upgrading immediately.

Acknowledgments

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

Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend
Framework, please report it to us at zf-security@zend.com. We will
work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

Component(s) affected

A description indicating how to reproduce the issue

A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the
project contributors a chance to resolve the vulnerability and issue a new
release prior to any public exposure; this helps protect Zend Framework
users and provides them with a chance to upgrade and/or update in order to
protect their applications.

Policy

We will patch the current release branch, as well as the immediate prior
minor release branch.

After patching the release branches, we will immediately issue new
security fix releases for each patched release branch.

A security advisory will be released on the Zend Framework site
detailing the vulnerability, as well as recommendations for end-users to
protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as
via a feed (which is also present in the
website head for easy feed discovery)

SQL Server treats 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.

Developers using the relevant PDO_Sqlsrv adapter in any version
of Zend Framework are not vulnerable to this attack, as PDO provides
a native quoting mechanism that prevents the attack vector.

Action Taken

When quoting values for SQL server, we now pass them to PHP's addcslashes
function to sanitize and properly quote null bytes:

$value = addcslashes($value, "\000\032");

This action quotes null bytes, preventing SQL injection vectors.

The following releases contain the fixes:

Zend Framework 1.12.9

Zend Framework 2.2.8

Zend Framework 2.3.3

If you are using an affected version of PHP, and utilizing the sqlsrv PHP extensio
within Zend Framework, we highly recommend upgrading immediately.

Acknowledgments

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

Jonas Sandström, who discovered and reported the issue against the Zend_Db_Adapter_Sqlsrv component of ZF1;

Matthew Weier O'Phinney, who provided the patch.

Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend
Framework, please report it to us at zf-security@zend.com. We will
work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

Component(s) affected

A description indicating how to reproduce the issue

A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the
project contributors a chance to resolve the vulnerability and issue a new
release prior to any public exposure; this helps protect Zend Framework
users and provides them with a chance to upgrade and/or update in order to
protect their applications.

Policy

We will patch the current release branch, as well as the immediate prior
minor release branch.

After patching the release branches, we will immediately issue new
security fix releases for each patched release branch.

A security advisory will be released on the Zend Framework site
detailing the vulnerability, as well as recommendations for end-users to
protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as
via a feed (which is also present in the
website head for easy feed discovery)

PHP's LDAP extension provides bindings to the C-based OpenLDAP library,
including the ldap_bind function, to perform LDAP binds. The PHP-side function
takes an LDAP connection object, username (DN), and password string as
arguments, with its semantics being the same as the OpenLDAP ldap_bind
function called with the LDAP_AUTH_SIMPLE method argument.

PHP passes the PHP string arguments to the OpenLDAP C function - which expects
C-style null-terminated strings - by passing a pointer to the PHP string's
value data in memory. String values in PHP can contain arbitrary byte values,
including the null character (byte value 0x00). If an argument to PHP's
ldap_bind contains such a null byte, no special action is taken, so from the
OpenLDAP C ldap_bind function's point of view, such strings are truncated at
the first null byte.

Hence, an attacker can pass a string starting with a null byte as a password
when authenticating to an application that uses PHP's ldap_bind. This will, in
many cases, bypass the application's own check for a non-empty password (since
the string is non-empty from PHP's perspective), but still appear to be empty
to the OpenLDAP ldap_bind function, leading to an unauthenticated bind being
performed against the application's intent. This allows an authentication bypass,
as the attacker can login as any given user without needing to know their real
LDAP password.

We used the PHP function ldap_bind() in the Zend\Ldap
component of ZF2 and in the Zend_Ldap class of ZF1.

The vulnerability was patched within PHP's LDAP extension starting with PHP
5.5.12 and PHP 5.4.28. Prior versions remain vulnerable, which is what the
patch associated with this advisory attempts addresses.

Action Taken

We filtered the password input, removing null bytes, using the following code:

If you are using an affected version of PHP, and utilizing the LDAP functionality
from Zend Framework, we highly recommend upgrading immediately.

Acknowledgments

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

Matthew Daley, who discovered and reported the issue in Zend\Ldap component of ZF2;

Enrico Zimuel, who provided the patch.

Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend
Framework, please report it to us at zf-security@zend.com. We will
work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

Component(s) affected

A description indicating how to reproduce the issue

A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the
project contributors a chance to resolve the vulnerability and issue a new
release prior to any public exposure; this helps protect Zend Framework
users and provides them with a chance to upgrade and/or update in order to
protect their applications.

Policy

We will patch the current release branch, as well as the immediate prior
minor release branch.

After patching the release branches, we will immediately issue new
security fix releases for each patched release branch.

A security advisory will be released on the Zend Framework site
detailing the vulnerability, as well as recommendations for end-users to
protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as
via a feed (which is also present in the
website head for easy feed discovery)

]]>Thu, 17 September 2014 10:30:00 -0500zf-security@zend.com (Zend Framework Security)ZF2014-04: Potential SQL injection in the ORDER implementation of Zend_Db_Selecthttp://framework.zend.com/security/advisory/ZF2014-04
http://framework.zend.com/security/advisory/ZF2014-04ZF2014-04: Potential SQL injection in the ORDER implementation of Zend_Db_Select

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.

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.

Action Taken

We fixed the issue in the Zend_Db_Select::order() function
using a more granular regular expression to match only SQL functions in an
ORDER BY statement, such as ORDER BY
ABS("zfproducts"."product_id").

The new regular expression is '/^[\w]*\(.*\)$/' instead of the
previous '/\(.*\)/'.

This change fixes the issue, filtering the input using quotes for the previous attack.

The previous SQL example with the fix is rendered in the correct way:

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

The patch is available starting in Zend Framework 1.12.7.

Other Information

This SQL injection attack does not affect Zend Framework 2 versions because
the implementation of Zend\Db\Sql\Select::order() does 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:

Cassiano Dal Pizzol, who discovered the original issue;

Lars Kneschke, who analyzed and reported the issue;

Enrico Zimuel, who provided the patch.

Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend
Framework, please report it to us at zf-security@zend.com. We will
work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

Component(s) affected

A description indicating how to reproduce the issue

A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the
project contributors a chance to resolve the vulnerability and issue a new
release prior to any public exposure; this helps protect Zend Framework
users and provides them with a chance to upgrade and/or update in order to
protect their applications.

Policy

We will patch the current release branch, as well as the immediate prior
minor release branch.

After patching the release branches, we will immediately issue new
security fix releases for each patched release branch.

A security advisory will be released on the Zend Framework site
detailing the vulnerability, as well as recommendations for end-users to
protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as
via a feed (which is also present in the
website head for easy feed discovery)

zf-apigility contains a class,
ZF\Apigility\DbConnectedResource, used by all DB-Connected REST services for
prototyping web services that write to a database table, or for simple CRUD-style web
services.

This class was correctly pulling data from the composed input filter, if any, for
create() operations. However, it was not doing so for update()
and patch() operations, leading to the potential for unfiltered data to
make its way to the database.

Note, however, that this is not a SQL injection vulnerability, as database updates
were still using the underlying database abstraction layer. However, in cases where
values are expected to be normalized, unfiltered versions could enter the database;
additionally, if any data not matching existing database columns were provided, database
errors could occur.

Action Taken

Each of the create(), update(), and patch() operations
in the ZF\Apigility\DbConnectedResource class were updated to always pull data from
the composed input filter when present.

The following releases contain the fixes:

zf-apigility 1.0.2

Apigility (zf-apigility-skeleton) 1.0.3

Other Information

Acknowledgments

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

Many Zend Framework 2 view helpers were using the escapeHtml()
view helper in order to escape HTML attributes, instead of the more appropriate
escapeHtmlAttr(). In situations where user data and/or
JavaScript is used to seed attributes, this can lead to potential cross site scripting (XSS)
attack vectors.

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.

How the attack works

To realize the attack, we set up a malicious OpenID Provider (e.g.
"http://openid.evil.com") that is able to generate valid OpenID tokens
containing arbitrary openid.identifier and
openid.claimed_id values. At that point, we can
successfully authenticate with the issued identity controlled by our
Identity Provider, e.g. "http://openid.evil.com?identity=bob". This confirms
that our Identity Provider works correctly. Then we log out. Afterwards, we
start the same login procedure, i.e. we submit the same Identity again
("http://openid.evil.com?identity=bob"). According to the OpenID
specification, we are redirected to our Identity Provider
("http://openid.evil.com"). But this time, we configure our Identity
Provider to ignore the requested identity ("http://openid.evil.com?identity=bob")
and instead use a victim's identity (e.g. openid.claimed_id=http://victim.myopenid.com/,
openid.identity=http://victim.myopenid.com/, and additionally
op_endpoint=http://www.myopenid.com/server).

All other openid.* parameters are used as requested. Note that our
Identity Provider is not authorized to issue tokens in the name of other
Identity Providers (such as MyOpenID, Google, etc.). However, the token is
accepted by the framework. In this manner we could impersonate other
users/identities without knowing any credentials and secrets.

Action Taken

We have made the following changes to ZendOpenId\Consumer\GenericConsumer
and Zend_OpenId_Consumer classes:

During the verify() method of the consumer, if the openid_op_endpoint value is different from the previous server, related to the same openid_assoc_handle, we return false, reporting an error.

Other Information

Acknowledgments

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

Christian Mainka (Christian.Mainka@rub.de) and Vladislav Mladenov (vladislav.mladenov@rub.de) researchers at the Ruhr-University Bochum for alerting us to the issue and for the suggestions on how to fix it;

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.

Action Taken

Continuing on the patches performed in ZF2012-02
and ZF2012-05,
we extended the patch to all the usage of the PHP functions
simplexml_load_*, DOMDocument::loadXML, and
xml_parse, in order to prevent XXE and XEE attacks across
the framework.

We have provided new components, Zend_Xml_Security in ZF1 and
the standalone ZendXml, that scan and load XML documents to
prevent the previous attacks. The XXE attack is prevented using the
libxml_disable_entity_loader() function to
disable the loading of ENTITY nodes. The XXE attack is prevented by checking
for the presence of ENTITY elements in the document type declaration; in
such cases, we throw an Exception with an error message indicating that we
don't accept ENTITY declarations in XML documents for security reasons.

Moreover, because of PHP
bug 64938, we have decided to manage the PHP-FPM scenario using an
heuristic approach. We perform a search inside the XML string to find usage of any
<!ENTITY" element, and, on detection, raise an exception.

Note: the libxml library used by PHP to manage XML documents has been fixed
against XEE attacks starting from libxml2 version 2.9. If you are using this
version you can use the existing PHP functions without security concerns.

The following components/libraries were patched, at the version specified:

The Zend\Http\PhpEnvironment\RemoteAddress class provides features
around detecting the internet protocol (IP) address for an incoming proxied
request via the X-Forwarded-For header, taking into account a
provided list of trusted proxy server IPs. Prior to 2.2.5, the
class was not taking into account whether or not the IP address contained
in PHP's $_SERVER['REMOTE_ADDR'] was in the trusted proxy server
list.

The IETF draft
specification indicates that if $_SERVER['REMOTE_ADDR'] is not
a trusted proxy, it must be considered the originating IP address, and
the value of X-Forwarded-Formust be disregarded.

Action Taken

We have made the following change to the Zend\Http\PhpEnvironment\RemoteAddress class:

If we detect that (a) we will test against proxy servers, and (b)
$_SERVER['REMOTE_ADDR'] is not in the list of trusted proxy servers,
we now return the value of $_SERVER['REMOTE_ADDR'] immediately, without
introspecting the X-Forwarded-For header.

Recommendations

You are only affected by this as an issue if you directly consume one of the
following in your code:

Zend\Http\PhpEnvironment\RemoteAddress

Zend\Session\Validator\RemoteAddr

If you do, we recommend immediately upgrading to version 2.2.5.

Other Information

Acknowledgments

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

Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend
Framework, please report it to us at zf-security@zend.com. We will
work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

Component(s) affected

A description indicating how to reproduce the issue

A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the
project contributors a chance to resolve the vulnerability and issue a new
release prior to any public exposure; this helps protect Zend Framework
users and provides them with a chance to upgrade and/or update in order to
protect their applications.

Policy

We will patch the current release branch, as well as the immediate prior
minor release branch.

After patching the release branches, we will immediately issue new
security fix releases for each patched release branch.

A security advisory will be released on the Zend Framework site
detailing the vulnerability, as well as recommendations for end-users to
protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as
via a feed (which is also present in the
website head for easy feed discovery)

The Zend\Db component in Zend Framework 2 provides platform
abstraction, which is used in particular for SQL abstraction. Two methods
defined in the platform interface, quoteValue() and
quoteValueList(), allow users to manually quote values for
creating SQL statements; these are in turn consumed by aspects of the
SQL abstraction platform, including Zend\Db\Sql\Sql::getSqlStringForSqlObject(),
and the getSqlString() method provided in a number of
classes in the Zend\Db\Sql namespace.

While these methods are primarily intended for debugging and logging purposes,
developers can use them to produce SQL that is then passed to the driver to
execute. Due to a flaw in how the quoteValue() and
quoteValueList() methods were written, this can lead to potential
SQL injection.

The offending code is located in any of the Zend\Db\Adapter\Platform*
objects, particularly the quoteValue() and quoteValueList() methods. These
methods did not take into account most of the possible escapable characters
that would need to be escaped when attempting to create a quoted value for
interpolation into a SQL string. Moreover, these methods did value quoting
without extension level coordination which, when available, takes
character-sets into account when quoting.

Action Taken

We have made the following changes to the Platform objects:

Platform objects now accept the Driver as an optional parameter. This
allows quoteValue() to use the driver level quoting/escaping mechanism to
provide an "as safe as possible" value.

If a driver level quoting/escaping function is not available, the
Platform object will throw an E_USER_NOTICE.

A new API was introduced for the use cases that need quoting without
the possibility of a warning being triggered:
Zend\Db\Adapter\Platform\PlatformInterface::quoteTrustedValue().

Recommendations

You are only affected by this as an issue if you directly consume one of the
following API's in your code, and execute the results with
your database adapter:

Zend\Db\Adapter\Platform*::quoteValue()

Zend\Db\Adapter\Platform*::quoteValueList()

Zend\Db\Sql\Sql->getSqlStringForSqlObject()

Zend\Db\Sql\Select->getSqlString()

Zend\Db\Sql\Insert->getSqlString()

Zend\Db\Sql\Update->getSqlString()

Zend\Db\Sql\Delete->getSqlString()

ZF2's Zend\Db and other components that utilize
Zend\Db never directly rely on interpolation of values into SQL
strings. This means that unless you find any of the above calls in your code,
or any code that effectively calls quoteValue(), this issue does
not affect you.

If you do, however, we recommend immediately upgrading to either version
2.0.8 or 2.1.4.

While this advice can be found in many places, it is always worth
repeating: you should never rely on interpolation of values into SQL
strings; always use prepared statements / parameterization / extension
specific value binding.

Other Information

Acknowledgments

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

Axel Helmert for alerting us to the issue

Ralph Schindler for implementing a solution

Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend
Framework, please report it to us at zf-security@zend.com. We will
work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

Component(s) affected

A description indicating how to reproduce the issue

A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the
project contributors a chance to resolve the vulnerability and issue a new
release prior to any public exposure; this helps protect Zend Framework
users and provides them with a chance to upgrade and/or update in order to
protect their applications.

Policy

We will patch the current release branch, as well as the immediate prior
minor release branch.

After patching the release branches, we will immediately issue new
security fix releases for each patched release branch.

A security advisory will be released on the Zend Framework site
detailing the vulnerability, as well as recommendations for end-users to
protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as
via a feed (which is also present in the
website head for easy feed discovery)

In Zend Framework 2, the Zend\Math\Rand component generates
random bytes using the OpenSSL or Mcrypt extensions when available but will
otherwise use PHP's mt_rand() function as a fallback. All
outputs from mt_rand() are predictable for the same PHP
process if an attacker can brute force the seed used by the
Marsenne-Twister algorithm in a Seed Recovery Attack. This attack can be
successfully applied with minimum effort if the attacker has access to
either a random number from mt_rand() or a Session ID
generated without using additional entropy. This makes
mt_rand() unsuitable for generating non-trivial random bytes
since it has Insufficient Entropy to protect against brute force attacks on
the seed.

The Zend\Validate\Csrf component generates CSRF tokens by SHA1
hashing a salt, random number possibly generated using
mt_rand() and a form name. Where the salt is known, an
attacker can brute force the SHA1 hash with minimum effort to discover the
random number when mt_rand() is utilised as a fallback to the
OpenSSL and Mcrypt extensions. This constitutes an Information Disclosure
where the recovered random number may itself be brute forced to recover the
seed value and predict the output of other mt_rand() calls for
the same PHP process. This may potentially lead to vulnerabilities in
areas of an application where mt_rand() calls exist beyond the
scope of Zend Framework.

Action Taken

Zend Framework have revised the Zend\Math\Rand component to replace the
current mt_rand() fallback for OpenSSL/Mcrypt with Anthony Ferrara's
RandomLib, incorporating an additional
entropy source based on source code published by George Argyros. The new
fallback collects entropy from numerous sources other than PHP's internal seed
mechanism and extracts random bytes from the resulting mixed entropy pool.

Recommendations

If you are using either Zend\Math\Rand or
Zend\Validate\Csrf, do not have either the OpenSSL or Mcrypt
extensions installed in PHP, and are on a non-Unix-like system, we
recommend upgrading immediately to version 2.0.8 or 2.1.4.

Other Information

Acknowledgments

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

Pádraic Brady for identifying and reporting the issue, as well as providing a patch to resolve the issue

Enrico Zimuel for collaborating on and reviewing the solution

Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend
Framework, please report it to us at zf-security@zend.com. We will
work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

Component(s) affected

A description indicating how to reproduce the issue

A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the
project contributors a chance to resolve the vulnerability and issue a new
release prior to any public exposure; this helps protect Zend Framework
users and provides them with a chance to upgrade and/or update in order to
protect their applications.

Policy

We will patch the current release branch, as well as the immediate prior
minor release branch.

After patching the release branches, we will immediately issue new
security fix releases for each patched release branch.

A security advisory will be released on the Zend Framework site
detailing the vulnerability, as well as recommendations for end-users to
protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as
via a feed (which is also present in the
website head for easy feed discovery)

In Zend Framework 2, Zend\Mvc\Router\Http\Query is used
primarily to allow appending query strings to URLs when assembled. However,
due to the fact that it captures any query parameters into the
RouteMatch, and the fact that RouteMatch
parameters are merged with any parent routes, this can lead to overriding
already captured routing parameters, bypassing constraints defined in the
parents.

This would lead to execution of a different controller than intended, with a
value for the key parameter that bypassed the constraints outlined
in the parent route.

Action Taken

Zend Framework 2.1 introduced changes to the router implementation that now
allows passing both query string values and fragment values during URI
assembly, effectively obsoleting the original use case of the Query
route. As an example, you can now do the following:

As such, for versions 2.0.8 and 2.1.4, we have marked
Zend\Mvc\Router\Http\Query deprecated. Additionally, we have
modified the code in its match() method to no longer pass
the query parameters to the RouteMatch, eliminating the
possibility of route parameter injection entirely.

Recommendations

If you are using the Query route in Zend Framework 2, we
recommend upgrading to Zend Framework 2.0.8 or 2.1.4 immediately.

Other Information

Acknowledgments

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

Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend
Framework, please report it to us at zf-security@zend.com. We will
work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

Component(s) affected

A description indicating how to reproduce the issue

A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the
project contributors a chance to resolve the vulnerability and issue a new
release prior to any public exposure; this helps protect Zend Framework
users and provides them with a chance to upgrade and/or update in order to
protect their applications.

Policy

We will patch the current release branch, as well as the immediate prior
minor release branch.

After patching the release branches, we will immediately issue new
security fix releases for each patched release branch.

A security advisory will be released on the Zend Framework site
detailing the vulnerability, as well as recommendations for end-users to
protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as
via a feed (which is also present in the
website head for easy feed discovery)

Zend_Feed_Rss and Zend_Feed_Atom were found to
contain potential XML eXternal Entity (XXE) vectors due to insecure usage of
PHP's DOM extension. External entities could be specified by adding a specific
DOCTYPE element to feeds; exploiting this vulnerability could
coerce opening arbitrary files and/or TCP connections.

A similar issue was fixed for 1.11.13 and 1.12.0, in the
Zend_Feed::import() factory method; however, the reporter of
the issue discovered that the individual classes contained similar
functionality in their constructors which remained vulnerable.

Action Taken

A patch was applied that removes the XXE vector by calling
libxml_disable_entity_loader() before attempting to parse the feed via
DOMDocument::loadXML().

Recommendations

If you are using any of the components listed, and, in particular, were
directly instantiating them, we recommend upgrading to either version
1.11.15 or 1.12.1 or greater.

Other Information

Acknowledgments

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

Yury Dyachenko at Positive Research Center

Reporting Potential Security Issues

If you have encountered a potential security vulnerability in Zend
Framework, please report it to us at zf-security@zend.com. We will
work with you to verify the vulnerability and patch it.

When reporting issues, please provide the following information:

Component(s) affected

A description indicating how to reproduce the issue

A summary of the security vulnerability and impact

We request that you contact us via the email address above and give the
project contributors a chance to resolve the vulnerability and issue a new
release prior to any public exposure; this helps protect Zend Framework
users and provides them with a chance to upgrade and/or update in order to
protect their applications.

Policy

We will patch the current release branch, as well as the immediate prior
minor release branch.

After patching the release branches, we will immediately issue new
security fix releases for each patched release branch.

A security advisory will be released on the Zend Framework site
detailing the vulnerability, as well as recommendations for end-users to
protect themselves. Security advisories will be listed at http://framework.zend.com/security/advisories, as well as
via a feed (which is also present in the
website head for easy feed discovery)