Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19208 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91712 invoked by uid 1010); 27 Sep 2005 16:32:04 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 91697 invoked from network); 27 Sep 2005 16:32:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Sep 2005 16:32:04 -0000 X-Host-Fingerprint: 216.27.179.240 dsl027-179-240.sfo1.dsl.speakeasy.net Linux 2.4/2.6 Received: from ([216.27.179.240:22021] helo=panda.ibink.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 8A/40-54476-30479334 for ; Tue, 27 Sep 2005 12:32:04 -0400 Received: from pomegranate.ibink.com ([10.100.1.21]) by panda.ibink.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.35 #1 (Debian)) id 1EKIN5-0000Go-00; Tue, 27 Sep 2005 09:31:59 -0700 Message-ID: <433973F4.2020103@ibink.com> Date: Tue, 27 Sep 2005 09:31:48 -0700 User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: internals@lists.php.net, Magpierss-general@lists.sourceforge.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Comment on Bug #30153: FATAL erealloc() error when using gzinflate() From: php.net@ibink.com (Tim Nufire) 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. Thanks, Tim