# Comment on Bug #30153: FATAL erealloc() error when using gzinflate() - Thread: https://externals.io/message/19208 - Original archive: https://news-web.php.net/php.internals/19208 - Started by Tim Nufire on 2005-09-27T16:31:48+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #19208 — Tim Nufire — 2005-09-27T16:31:48+00:00 URL: https://externals.io/message/19208#19208 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 --- ## #19209 — Rasmus Lerdorf — 2005-09-27T16:49:25+00:00 URL: https://externals.io/message/19208#19209 · In reply to: #19208 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 --- ## #19403 — Tim Nufire — 2005-10-04T15:50:00+00:00 URL: https://externals.io/message/19208#19403 · In reply to: #19209 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: > > > > […] > >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 --- ## #19404 — George Schlossnagle — 2005-10-04T15:54:56+00:00 URL: https://externals.io/message/19208#19404 · In reply to: #19403 > 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 --- ## #19406 — Tim Nufire — 2005-10-04T16:24:33+00:00 URL: https://externals.io/message/19208#19406 · In reply to: #19404 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: > > > > > […] > > > 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 --- ## #19407 — Ron Korving — 2005-10-04T18:16:18+00:00 URL: https://externals.io/message/19208#19407 · In reply to: #19406 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" 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: > > > […] --- ## #19410 — Tim Nufire — 2005-10-04T20:44:43+00:00 URL: https://externals.io/message/19208#19410 · In reply to: #19407 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" wrote in message >news:4342ACC1.2030106@ibink.com... > > > > […] --- ## #19416 — Ron Korving — 2005-10-05T06:24:15+00:00 URL: https://externals.io/message/19208#19416 · In reply to: #19410 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" 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: > > > […] one > > […] --- ## #19417 — William A. Rowe — 2005-10-05T06:36:28+00:00 URL: https://externals.io/message/19208#19417 · In reply to: #19416 Perhaps this is a stupid question, but has anyone ensured that zlib rev 1.2.3 still exhibits this behavior? The trouble ticket is close to useless for recapping this; but I'm happy to shepard a fix or some solution through the zlib dev team. The ticket indiciated that PHP is using it's own fork of zlib, perhaps I'm confused on the issue, though. All versions pre-1.1.4 and pre-1.2.3 are known-vulnerable, so there's really no point in reproducing these problems on anything other than the current rev 1.2.3. Bill 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. --- ## #19481 — Tim Nufire — 2005-10-07T17:18:23+00:00 URL: https://externals.io/message/19208#19481 · In reply to: #19416 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" schreef in bericht > news:4342E9BB.1010902@ibink.com... > > > […] > one > > > […]