Re: Comment on Bug #30153: FATAL erealloc() error whenusinggzinflate()

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