Reporter Credit: @real_as3617, @gPayl0ad

file() filetime() filectime() fileatime() file_put_contents() fileinode() file_exists() filegroup() fileowner() file_get_contents() fopen() fileperms() is_dir() is_readable() is_executable() is_writable() is_writeable() is_file() is_link() parse_ini_file() copy() unlink() stat() readfile()

dos can occur in all functions where phar wrapper is available

Also, since the code of phar.c has rarely been updated, it is expected to work the same in latest version of php.

Thank you for reporting this issue!

I was not aware of compressed file quines[1], but indeed, these
would cause an infinite loop with all relevant PHP versions.

Suggested patch: <https://gist.github.com/cmb69/77ad17bf57c6ef35785476d5328b4b74>.

Stas, what do you think?

[1] <https://honno.dev/gzip-quine/>

phar are mostly code archive

So if you allow phar from untrusted sources, of course this may raise lot of issues.

IMHO this should be manage as (at most) "low" security
(and thus go thru next RC without a need for a CVE)

I'm not sure what's going on here - why would phar try repeatedly to decompress the same archive? Isn't once enough?

The code in example is obviously insecure (you can force it to work as open proxy, or do other nasty stuff with various wrappers) but if it has problems with phar:// on something as simple as file_exists, it still can be a problem, because inspecting phars doesn't seem to be an inherently insecure operation. I don't think it'd execute the stub when inspecting it, or something like that?

Of course, allowing phar wrapper can cause many security problems, but I don't think this bug has a low severity. The important thing about this bug is that all php workers fall infinite loop in just a few requests.
And that poc is the most extreme example.
The same bug occurs when using the poc of CVE-2020-7068.

----- ----- php.ini -----
+ + phar.cache_list =/path/2xq.gz
-------------------

https://bugs.php.net/bug.php?id=79797
Of course, this bug was published with a cve.

And, I agree with stats. just once is enough.

oh sorry. not stats but stas

To clarify, this issue does not only affect the phar stream
wrapper, but also the PharData class, which is not supposed to
cause such issues, and is likely not rarely used to deal with .tgz
files.  A simple

    new PharData(__DIR__ . "/quine.tgz");

causes an infinite loop.

> Isn't once enough?

Maybe, but at least wrt. backwards compatibility I wouldn't
disallow multiple passes for now; after all, a gzip compressed
file might have been gzip compressed again (maybe accidentially),
and that is handled fine.

> a gzip compressed file might have been gzip compressed again (maybe accidentially), and that is handled fine.

What do you mean here by "handled fine"? If you gzip a gzipped file again, then nobody I think expects that after you run "gzip -d" on it, it'd try to decompress it infinitely until it gets to the "original" - the expectation would be it runs decompression once. I don't see why the expectation for phar should be any different.

> the expectation would be it runs decompression once

Fair enough.  Still, for BC reasons we probably should not change
that in a stable version, at least not in PHP 7.4.

any progress?

This issue is scheduled to be fixed with the next GA releases
(2022-09-29).  A slight variation of my suggested patch will be
used (with recursion_count = 3 instead of 100).

can i get cve?

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php