This repository was archived by the owner on May 16, 2018. It is now read-only.
Cannot parse huge documents in Zend_Dom_Query #504
Labels
Milestone
Comments
|
@croensch |
|
ping @croensch |
dsikkema-magento
pushed a commit
to magento/zf1
that referenced
this issue
Sep 30, 2015
Zend Framework 1.12.16 - [504: Cannot parse huge documents in Zend&zendframework#95;Dom&zendframework#95;Query](zendframework#504) - [599: Wrong return type in DocBlock of Zend&zendframework#95;Console&zendframework#95;Getopt::getOption()](zendframework#599) - [600: Undefined property $config in Zend&zendframework#95;Http&zendframework#95;Client&zendframework#95;Adapter&zendframework#95;Curl](zendframework#600) - [604: add doccomments to Zend&zendframework#95;Log covering its magic methods](zendframework#604) - [606: Fix typo in Zend&zendframework#95;Cache-Backends documentation.](zendframework#606) - [610: Add ß (Latin small letter sharp s) to .de domain IDNA check](zendframework#610) - [612: Zend&zendframework#95;Validate&zendframework#95;Hostname does not validate NTP hostnames starting with '0' character](zendframework#612) SECURITY UPDATES ---------------- - **ZF2015-07**: A number of components, including `Zend_Cloud`, `Zend_Search_Lucene`, and `Zend_Service_WindowsAzure` were creating directories with a liberal umask that could lead to local arbitrary code execution and/or local privilege escalation. This release contains a patch that ensures the directories are created using permissions of 0775 and files using 0664 (essentially umask 0002). - **ZF2015-08**: ZF2014-06 uncovered an issue in the sqlsrv adapter provided by the framework whereby null bytes were not filtered correctly when generating SQL. A reporter discovered the same vulnerability is present in our PDO implementation when used with pdo_dblib, and could potentially be applied to other PDO adapters. This release contains a patch to properly escape null bytes used in SQL queries across all PDO adapters shipped with the framework. Conflicts: README.md
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In
Zend_Dom_Query::queryXpath()the document is only a string and the HTML/XML loading is hard coded so that passing an option like$domDoc->loadHTML($document, LIBXML_PARSEHUGE);is impossible.
The result is that the found nodes may be truncated.
If we could inject a DOMDocument object instead, right into
Zend_Dom_Query::setDocument(), the loading of the Document could happen outside of the existing code.The text was updated successfully, but these errors were encountered: