Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19481
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4346ADDF.4010809@ibink.com>
Date: Fri, 07 Oct 2005 10:18:23 -0700
User-Agent: Thunderbird 1.4 (Windows/20050908)
MIME-Version: 1.0
To: Ron Korving <r.korving@xit.nl>
CC: internals@lists.php.net
References: <433973F4.2020103@ibink.com> <43397815.2030000@lerdorf.com> <4342A4A8.9090103@ibink.com> <362F3EA1-D850-429E-8889-54675FCEB920@omniti.com> <4342ACC1.2030106@ibink.com> <74.A2.54476.28AC2434@pb1.pair.com> <4342E9BB.1010902@ibink.com> <DB.4E.54476.C9173434@pb1.pair.com>
In-Reply-To: <DB.4E.54476.C9173434@pb1.pair.com>
Content-Type: multipart/alternative;
	boundary="------------040502020906020106070901"
Subject: Re: [PHP-DEV] Comment on Bug #30153: FATAL erealloc() error whenusinggzinflate()
From: php.net@ibink.com (Tim Nufire)

--------------040502020906020106070901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ron,

I agree that a bug report should be filed against zlib, but 
unfortunately I don't know enough about the underlying issues to file 
that report myself.... I do have enough context to file a new bug 
against PHP but feel that bug #30153 does a great job of describing the 
issue and believe it should just be re-opened. If that is not possible I 
will create a new report.

Tim

Ron Korving wrote:
> My bad, I remembered the initial post wrong. Still, the primary bug report
> should be for the zlib fellas. They're the ones who need to fix their lib.
> Secondary, maybe php folks can see if the problem can be worked around. But
> still, the guys with the real problem are the zlib guys. Have you filed a
> bugreport there? That should be the primary action in this situation.
>
> Ron
>
> "Tim Nufire" <tnufire@ibink.com> schreef in bericht
> news:4342E9BB.1010902@ibink.com...
>   
>> Ron,
>>
>> But the error I'm seeing is *not* a segfault... Bad input data causes
>> unbounded memory allocations which are eventually terminated when the
>> per script memory limit is hit. At this point, PHP traps the condition
>> and terminates the script 'gracefully'. The problem is that a 'graceful'
>> termination of the script does not give the script itself a chance to
>> handle the error. While I have not dug into the PHP code, I don't
>> understand why the technique used to cap memory usage at the script
>> level can't be used to detect a problem in zlib.... Perhaps passing a
>> max memory usage parameter to gzinflate that is lower that the script
>> limit would be the right solution here. Is this possible?
>>
>> Tim
>>
>> Ron Korving wrote:
>>
>>     
>>> Tim,
>>>
>>> I'm no core PHP developer (just a user) but I'm pretty convinced that
>>> there's nothing that can be done to solve this from PHP. PHP just passes
>>> bytes to the zlib functions (which are implemented by the zlib guys). If
>>>       
> one
>   
>>> of these functions causes a segfault, there's really nothing you can do.
>>> Zlib just shouldn't segfault, but return a nice clean error. That's where
>>> the problem is. Once zlib segfaults, PHP segfaults (it's all the same
>>> process). I don't think there's any way to manage this behavior from PHP.
>>>
>>> Ron
>>>
>>>
>>> "Tim Nufire" <php.net@ibink.com> wrote in message
>>> news:4342ACC1.2030106@ibink.com...
>>>
>>>
>>>       
>>>> This is starting to sound like the dispute in the initial bug
>>>> report..... Regardless of the root cause, this is a serious bug in PHP
>>>> which exposes any script using gzinflate to denial of service attacks.
>>>> While I'm sure extending zlib provides the most elegant fix to this
>>>> problem, it should be possible to protect PHP scripts from crashes
>>>> without such extensions. At the very least, the documentation should
>>>> include a warning about this vulnerability..... I agree that a bug
>>>> should be filed against zlib as well but don't understand why there is
>>>> so much resistance to tracking this in the PHP bug database. I am not
>>>> the right person to file the zlib bug since I don't know enough about
>>>> what is needed there but I can open a new bug in the PHP db if reopening
>>>> 30153 is not the right answer.
>>>>
>>>> Tim
>>>>
>>>> George Schlossnagle wrote:
>>>>
>>>>
>>>>
>>>>         
>>>>> On Oct 4, 2005, at 11:50 AM, Tim Nufire wrote:
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> 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....
>>>>>>
>>>>>>
>>>>>>             
>>>>> You should file a bug against zlib, as it is the library that needs
>>>>> to export these sorts of validation methods.  If/when zlib supports
>>>>> this sort of feature, PHP will support it.
>>>>>
>>>>> George
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>
>>>       
>
>
>   

--------------040502020906020106070901--