Hey All,
I've looked into this issue report to some detail and can say that this
is not an issue within ZF itself. As noted by the report, this is an
issue in PHPIDS, particularly when using a potentially unsafe operation
(/e modifier in a PregReplace filter, without sanitation)- not in ZF.
Please feel free to explore both the report and the ZF codebase itself.
If you find a way to write code that consumes ZF in a non-destructive
manner (ie. you don't use bad practices, such as eval() in your own
code), and are still be able exercise an exploit in Zend Framework,
please let me know at zf-secur...@zend.com.
Thanks!
-Ralph
Hector Virgen wrote:
Maybe when Zend_Log is serialized/unserialized, it should clear all
writers, similar to how unserializing a Zend_Db_Row instance results in
a "disconnected" row. But I'm not sure how to "reconnect" the writers in
the event that a developer wants to legitimately unserialize a logger
(perhaps for caching purposes).
If there was a reloadWriters() method that needed to be called in order
to unserialize the writers, would that help?
--
Hector
On Fri, Feb 19, 2010 at 7:19 AM, Nick Pack <n...@nickpack.com
<mailto:n...@nickpack.com>> wrote:
Hi All,
Wondering if anyone has seen this (I know the article itself is
related to PHPIDS, but includes ZF):
https://www.sektioneins.de/en/advisories/advisory-022009-phpids-unserialize-vulnerability/index.html
It highlights some possible exploitable flaws in Zend_Log and
Zend_Log_Writer_Mail – do these need looking at?
