Bug #73361 [Asn]: Out-of-bounds reads issue of php 5.6.27

Edit report at https://bugs.php.net/bug.php?id=73361&edit=1 ID: 73361 Updated by: cmb@php.net Reported by: 271193918 at qq dot com Summary: Out-of-bounds reads issue of php 5.6.27 Status: Assigned Type: Bug Package: Scripting Engine problem Operating System: Ubuntu 16.04 x86 PHP Version: 5.6.27 Assigned To: cmb Block user comment: N Private report: N New Comment: > […], 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> Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2016-10-24 06:26:02] stas@php.net Wait, I just noticed. Why you use php -c option? This makes php read exif_read_data.php as config file and ./crashes/fuzzer01/id_000194,sig_11,src_024221+025505,op_splice,rep_2 as a script. That's not how it's usually supposed to work. ------------------------------------------------------------------------ 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