Tim Nufire wrote: > Reposting from php-general@lists.php.net to the internals@lists.php.net > list because I'm told that's the right place for a discussion like this.... > > In tracking down a bug that I am seeing on a site I work on, I came > across bug #30153 (http://bugs.php.net/bug.php?id=30153). I must say I > am shocked that this bug was closed as 'bogus'.... Not only is this a > bug, it is a security issue! How can gzinflate not be responsible for > validating the content passed to it? Not doing so exposes PHP servers > that use this function to serious denial of service attacks.... > > Let me illustrate this issue using Magpierss > (http://magpierss.sourceforge.net) which uses gzinflate to support > gziped RSS feeds. Because Magpierss gets the compressed content from a > foreign server, it does not control its validity. The only way to see if > it is valid is to try to decompress it... Since this will crash the > script when the content is not valid, using gzinflate in this way will > expose any RSS aggregator that uses Magpierss to denial of service > attacks. Since no other means are provide to validate the gzip content, > I am at a loss to suggest a workaround to the Magpierss authors... > > This is just one example. Any server which decompresses content that it > gets from a foreign source will have this same issue. IMO, crashing a > script is never the right way to indicate that an error has occurred. > Without a fix, gzinflate should only be used when the content comes from > a trusted source. > > If I am missing something here or if there is a workaround to this > problem, please let me know.
I agree it is a problem, but the fix isn't easy since the zlib library doesn't provide any help here. We'd welcome an intelligent patch for this. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
