Everything

php

Comment on Bug #30153: FATAL erealloc() error when using gzinflate()

php.internals

Tim Nufire

20 years ago

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

Rasmus Lerdorf

20 years ago

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

Tim Nufire

20 years ago

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:

George Schlossnagle

20 years ago

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

Tim Nufire

20 years ago

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:

Ron Korving

20 years ago

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...

Tim Nufire

20 years ago

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:

Ron Korving

20 years ago

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

William A. Rowe, Jr.

20 years ago

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:

Tim Nufire

20 years ago

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: