Executive Summary

In mid-March, 2010, the Dojo Foundation issued a Security Advisory indicating potential security issues with specific files in Dojo Toolkit. Details of the advisory may be found on the Dojo website:

• http://dojotoolkit.org/blog/post/dylan/2010/03/dojo-security-advisory/

In particular, several files in the Dojo tree were identified as having potential exploits, and the Dojo team also advised disabling or removing any PHP scripts in the tree when deploying to production.

Action Taken

Since the files in question have been patched on the Dojo release branches, the only action needed was a new release that contains a new build of Dojo based on the current release branch. In addition, code was added to the Zend Framework Dojo build script to strip out all PHP files as an extra precaution.

Recommendations

This particular vulnerability only affects those users who:

• Use Dojo, and more specifically,
• Use the Dojo build supplied by Zend Framework, or
• Have not updated their site already based on the recommendations of the recent announcement by the Dojo Foundation.

If you fall into one of these categories, we strongly recommend upgrading to the latest available Zend Framework release, or one of the following releases, immediately, and redeploying Dojo from the Dojo packages supplied with Zend Framework:

• 1.10.3
• 1.9.8

Alternately, upgrade from official Dojo packages, following the guidelines in the aforementioned advisory from the Dojo Foundation.

Other Information

Acknowledgments

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

• Paul Verhoeven, for alerting us to the original Dojo advisory
• Peter Higgins and James Burke, from the Dojo Toolkit team, for advice on how best to package Zend Framework's Dojo distribution

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.

For sensitive email communications, please use our PGP key.

Policy

Zend Framework takes security seriously. If we verify a reported security vulnerability, our policy is:

• 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)

Executive Summary

Zend_Json_Encoder was not taking into account the solidus character ("/") during encoding, leading to incompatibilities with the JSON specification, and opening the potential for XSS or HTML injection attacks when returning HTML within a JSON string.

Action Taken

Zend_Json_Encoder was patched to escape the solidus character when encoding PHP strings to JSON.

Recommendations

This particular vulnerability only affects those users who are either (a) using Zend_Json_Encoder directly, (b) requesting native encoding instead of usage of ext/json (e.g., by enabling the static $useBuiltinEncoderDecoder property of Zend_Json), or (c) on systems where ext/json is unavailable (e.g. RHEL, CentOS). If you are affected, we strongly recommend upgrading to the latest available Zend Framework release, or one of the following releases, immediately.

• 1.9.7
• 1.8.5
• 1.7.9

Other Information

Acknowledgments

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

• Pádraic Brady, who made the initial report and who worked with our team to ensure that the appropriate actions were taken

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.

For sensitive email communications, please use our PGP key.

Policy

Zend Framework takes security seriously. If we verify a reported security vulnerability, our policy is:

• 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)

Executive Summary

Zend_Service_ReCaptcha_MailHide had a potential XSS vulnerability. Due to the fact that the email address was never validated, and because its use of htmlentities() did not include the encoding argument, it was potentially possible for a malicious user aware of the issue to inject a specially crafted multibyte string as an attack via the CAPTCHA's email argument.

Action Taken

An EmailAddress validator was added by default to Zend_Service_ReCaptcha_MailHide (which may be replaced with any Zend_Validate_interface implementation), and the submitted email address is now passed through this validator prior to performing any markup generation. Additionally, accessors for setting and retrieving the encoding to use with htmlentities() have been provided, with a default value of UTF-8 used.

Recommendations

If you use Zend_Service_ReCaptcha_MailHide, it is strongly recommended that you upgrade to either the latest available Zend Framework release, or one of the following releases, immediately:

• 1.9.7
• 1.8.5
• 1.7.9

Other Information

Acknowledgments

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

• Pádraic Brady, who made the initial report and who worked with our team to ensure that the appropriate actions were taken

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.

For sensitive email communications, please use our PGP key.

Policy

Zend Framework takes security seriously. If we verify a reported security vulnerability, our policy is:

• 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)

Executive Summary

Zend_File_Transfer had a potential MIME type injection vulnerability for file uploads. In certain situations where either PHP's ext/finfo extension is not installed and the mime_content_type() function was not available on a system, Zend_File_Transfer would use the user provided value for the type embedded inside the $_FILES superglobal. Additionally, in cases where the functionality was available, but where a type could not be determined by one of them, Zend_File_Transfer would also fallback on the user provided type. Using user provided information for a file's MIME type in uploads is considered an insecure practice, as it provides attack vectors by malicious users.

Action Taken

This vulnerability has been fixed by returning "application/octet" in situations where the MIME type cannot be detected securely by PHP.

Recommendations

If you use this component, or other components that rely on it (e.g., Zend_Form_Element_File), we strongly recommend upgrading to the most current version of Zend Framework available, or one of the following versions.

• 1.9.7
• 1.8.5

Other Information

Acknowledgments

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

• Pádraic Brady, who made the initial report and who worked with our team to ensure that the appropriate actions were taken
• Thomas Weidner, who provided the patch used to resolve the issue issue tracker

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.

For sensitive email communications, please use our PGP key.

Policy

Zend Framework takes security seriously. If we verify a reported security vulnerability, our policy is:

• 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)

Executive Summary

Zend_Filter_StripTags contained an optional setting to allow whitelisting HTML comments in filtered text. Microsoft Internet Explorer and several other browsers allow developers to create conditional functionality via HTML comments, including execution of script events and rendering of additional commented markup. By allowing whitelisting of HTML comments, a malicious user could potentially include XSS exploits within HTML comments that would then be rendered in the final output.

Action Taken

The Zend Framework team has determined that since this vulnerability is so trivial to exploit, the functionality to allow whitelisting comments will now be disabled in this and all future releases. Additionally, the regular expression for stripping comments has been bolstered to properly remove comments containing HTML tags, nested comments, and comments ending with whitespace between the "--" and ending delimiter (">").

Recommendations

If you use this filter and were enabling the "allowComments" functionality, be advised that it is now silently ignored. We also recommend such users to upgrade to the latest available Zend Framework release, or one of the following releases, immediately.

• 1.9.7
• 1.8.5
• 1.7.9

Other Information

Acknowledgments

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

• Pádraic Brady, who made the initial report and who worked with our team to ensure that the appropriate actions were taken

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.

For sensitive email communications, please use our PGP key.

Policy

Zend Framework takes security seriously. If we verify a reported security vulnerability, our policy is:

• 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)

Executive Summary

Zend_Dojo_View_Helper_Editor was incorrectly decorating a TEXTAREA instead of a DIV. The Dojo team has reported that this has security implications as the rich text editor they use is unable to escape content for a TEXTAREA.

Action Taken

The primary rationale in Zend Framework for using a TEXTAREA with the Editor Dijit was to allow for graceful degradation in browser environments that do not support JavaScript. The component has been reworked such that we now decorate an HTML DIV, and provide a separate TEXTAREA within a NOSCRIPT tag for purposes of graceful degradation; content is escaped in the latter TEXTAREA.

Recommendations

If you use Zend_Dojo_View_Helper_Editor, it is strongly recommended that you upgrade to either the latest available Zend Framework release, or one of the following releases, immediately:

• 1.9.7
• 1.8.5
• 1.7.9

Other Information

Acknowledgments

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

• Pádraic Brady, who made the initial report and who worked with our team to ensure that the appropriate actions were taken
• Peter Petrison and Mark Corti, for raising related issues in the ZF issue tracker

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.

For sensitive email communications, please use our PGP key.

Policy

Zend Framework takes security seriously. If we verify a reported security vulnerability, our policy is:

• 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)

Executive Summary

A number of classes, primarily within the Zend_Form, Zend_Filter, Zend_Form, Zend_Log and Zend_View components, contained character encoding inconsistencies whereby calls to the htmlspecialchars() and htmlentities() functions used undefined or hard coded charset parameters. In many of these cases developers were unable to set a character encoding of their choice. These inconsistencies could, in specific circumstances, allow certain multibyte representations of special HTML characters pass through unescaped leaving applications potentially vulnerable to cross-site scripting (XSS) exploits. Such exploits would only be possible if a developer used a non-typical character encoding (such as UTF-7), allowed users to define the character encoding, or served HTML documents without a valid character set defined.

Action Taken

The afore-mentioned classes have been reworked to use a default character encoding of UTF-8 and now expose methods to allow developers set a custom character encoding.

In addition, a decision was made to default to UTF-8 for the internal encoding mechanisms used by Zend_View. If you were relying on Zend_View using ISO-8859-1 encoding previously, you may need to specify that encoding manually now. You may do so in several ways:

• If manually instantiating Zend_View:

  
  $view = new Zend_View(array('encoding' => 'ISO-8859-1'));
  // or:
  $view->setEncoding('ISO-8859-1');
      

• From your application.ini:

  
  resources.view.encoding = "ISO-8859-1"
      

Recommendations

First, we recommend using UTF-8 or ensuring your chosen character encoding is used consistently across all components to help prevent potential multibyte based XSS attacks against your application. We also recommend that developers ensure HTML documents are served with a valid character set defined, such as via the Content-Type header or inside the document itself.

Second, if you are using any of the Zend_Form, Zend_Filter, Zend_Form, Zend_Log or Zend_View components, we strongly recommend upgrading to Zend Framework 1.9.7 or above; regardless, it is always best to run the most current version of the framework.

Other Information

Acknowledgments

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

• Pádraic Brady, who made the initial report and who worked with our team to ensure that the appropriate actions were taken

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.

For sensitive email communications, please use our PGP key.

Policy

Zend Framework takes security seriously. If we verify a reported security vulnerability, our policy is:

• 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)

Executive Summary

Zend_Filter_StripTags is a filtering class analogous to PHP's strip_tags() function. In addition to stripping HTML tags and selectively keeping those provided in a whitelist, it also provides the ability to whitelist specific attributes to retain per whitelisted tag.

The reporter discovered that attributes that contained whitespace, and in paricular, line breaks, surrounding the attribute assignment operator would not be stripped, regardless of whether or not they were whitelisted. As examples of input affected:

<!-- newlines before and/or after assignment: -->
<a href="http://framework.zend.com/issues" onclick
=
"alert('Broken'); return false;">Issues</a>

When passed to the following code:

$filter = new Zend_Filter_StripTags(array('a' => array('href')));
$value  = $filter->($html);

then the "onclick" attribute would remain, even though it was not specified in the tag's whitelist. This could open potential cross-site scripting attack (XSS) vectors.

Action Taken

The functionality was patched, and the patch released starting in Zend Framework version 1.7.6.

Recommendations

If you were using Zend_Filter_StripTags and utlizing the attribute whitelisting functionality, you should immediately upgrade to Zend Framework 1.7.6 or above; regardless, it is always best to run the most current version of the framework.

Also, if relying on Zend_Filter_StripTags to prevent XSS, the only way to reliably do so is to strip all tags, and never to whitelist. If you are whitelisting, you should consider finding a reliable XSS filter through which to run your output; we recommend HTML Purifier.

Other Information

Acknowledgments

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

• Aleksey Rechinskiy, who made the initial report and provided a number of code samples that reproduced the issue

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.

For sensitive email communications, please use our PGP key.

Policy

Zend Framework takes security seriously. If we verify a reported security vulnerability, our policy is:

• 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)

Executive Summary

Zend_View is a component that utilizes PHP as a templating language. To utilize it, you specify "script paths" that contain view scripts, and then render() view scripts by specifying subdirectories within those script paths; the output is then returned as a string value which may be cached or directly output.

Zend_View::setScriptPath() in versions up to and including 1.7.4 include a potential Local File Inclusion vulnerability. If untrusted input is used to specify the script path and/or view script itself, a malicious attacker could potentially specify a system directory and thus render a system file.

As an example, if the user-supplied string "/etc/passwd" or a relative path that resolved to that file, was supplied to Zend_View::render(), that file would be rendered.

Action Taken

The functionality was patched starting in Zend Framework 1.7.5. From that release forward, the render() method checks for absolute paths and/or parent directory traversal in the file location passed, and throws an exception when detected.

However, to provide backwards compatibility for those who relied on the functionality, an additional flag was added which can be used to optionally disable the protection: the method setLfiProtection(false), or the constructor option "lfiProtection".

Recommendations

If you were passing user input directly to render(), you should immediately upgrade to Zend Framework 1.7.5 or above; regardless, it is always best to run the most current version of the framework.

Additionally, the Zend Framework team reminds developers never to trust user input; in particular, when using it to determine file system paths, appropriate filters and normalization should be performed to limit the directory trees in which a requested file may be located.

Other Information

Acknowledgments

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

• Grzegorz Nowicki, who made the initial report

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.

For sensitive email communications, please use our PGP key.

Policy

Zend Framework takes security seriously. If we verify a reported security vulnerability, our policy is:

• 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)