Edit report at https://bugs.php.net/bug.php?id=73361&edit=1
ID: 73361
Updated by: php-bugs@lists.php.net
Reported by: 271193918 at qq dot com
Summary: Out-of-bounds reads issue of php 5.6.27
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: Ubuntu 16.04 x86
PHP Version: 5.6.27
Assigned To: cmb
Private report: N
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
Previous Comments:
------------------------------------------------------------------------
[2016-10-26 07:29:34] cmb@php.net
> [â¦], but current exif code does not validate Unicode strings> properly.
The issue regarding zend_multibyte_encoding_converter()
is not related to this ticket, which is not about Exif at all. I
don't have the time to have a closer look at the
zend_multibyte_encoding_converter() issue, but according to PR
#293[1] it may not (yet) be an issue at all. Anyhow, this issue
should be discussed elsewhere. :-)
> The link to image> id_000194,sig_11,src_024221+025505,op_splice,rep_2 is:
Thanks. However, I can't see how this file is relevant. I want to
reproduce the OOB read when running:
php -c exif_read_data.php ./crashes/fuzzer01/id_000194,sig_11,src_024221+025505,op_splice,rep_2
The script exif_read_data.php is given in this ticket, but where
is
./crashes/fuzzer01/id_000194,sig_11,src_024221+025505,op_splice,rep_2?
[1] <https://github.com/php/php-src/pull/293>
------------------------------------------------------------------------
[2016-10-26 01:35:49] yohgaki@php.net
This may be not related directly to this issue, but current exif code does not validate Unicode
strings properly.
2634 /* XXX this will fail again if encoding_converter returns on error something
different than SIZE_MAX */
2635 if (!to || !from || zend_multibyte_encoding_converter(
2636 (unsigned char**)pszInfoPtr,
2637 &len,
2638 (unsigned char*)szValuePtr,
2639 ByteCount,
2640 to,
2641 from) == (size_t)-1) {
2642 len = exif_process_string_raw(pszInfoPtr, szValuePtr, ByteCount);
This doesn't seem good. We are better to return nothing when encoding is broken, just like
htmlspecialchars()/htmlentities().
@cmd Could you handle this issue. Just returning len=0 seems to work at glance.
If user insist to get broken data, we may provide function or ini option.
------------------------------------------------------------------------
[2016-10-26 00:57:45] 271193918 at qq dot com
The link to image id_000194,sig_11,src_024221+025505,op_splice,rep_2 is:
https://mega.nz/#!AxxAzCwZ!Sx6BQTyzZupL2sCeyYLK628sJChx6eN8D754zh0Xh00
------------------------------------------------------------------------
[2016-10-25 15:16:45] cmb@php.net
To be able to debug this issue we need a copy of
./crashes/fuzzer01/id_000194,sig_11,src_024221+025505,op_splice,rep_2
------------------------------------------------------------------------
[2016-10-24 06:26:58] stas@php.net
Maybe a weird parser bug, certainly not a security issue - nobody runs binary junk as PHP script.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=73361
--
Edit this bug report at https://bugs.php.net/bug.php?id=73361&edit=1