Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4342A4A8.9090103@ibink.com>
Date: Tue, 04 Oct 2005 08:50:00 -0700
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: internals@lists.php.net,  Magpierss-general@lists.sourceforge.net
References: <433973F4.2020103@ibink.com> <43397815.2030000@lerdorf.com>
In-Reply-To: <43397815.2030000@lerdorf.com>
Content-Type: multipart/alternative;
	boundary="------------070204010408030304090004"
Subject: Re: [PHP-DEV] Comment on Bug #30153: FATAL erealloc() error when
	using gzinflate()
From: php.net@ibink.com (Tim Nufire)

--------------070204010408030304090004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ramus,

Thanks for the response. Unfortunately, I don't have any great ideas on 
how to patch this and for now have just stopped using gzinflate :-/ Is 
there a way to reopen bug 30153? That description of this issue is 
pretty good and, even if the bug is hard to fix, it should still be 
tracked somewhere....

Tim

Rasmus Lerdorf wrote:

>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
>
>  
>

--------------070204010408030304090004--