root@TZDG001:/tmp/data2# valgrind -q ../php-7.0.4/sapi/cli/php test.php ret/crash13
==20538== Invalid read of size 8
==20538==    at 0xC70678: zend_mm_alloc_small (zend_alloc.c:1291)
==20538==    by 0xC70678: zend_mm_alloc_heap (zend_alloc.c:1358)
==20538==    by 0xC70678: _emalloc (zend_alloc.c:2442)
==20538==    by 0xC7696F: _estrndup (zend_alloc.c:2565)
==20538==    by 0x76BD95: phar_split_fname (phar.c:2229)
==20538==    by 0x732F19: phar_parse_url (stream.c:74)
==20538==    by 0x747A26: phar_wrapper_open_dir (dirstream.c:315)
==20538==    by 0xBA6BB7: _php_stream_opendir (streams.c:1982)
==20538==    by 0x85DDB2: spl_filesystem_dir_open (spl_directory.c:236)
==20538==    by 0x869E39: spl_filesystem_object_construct (spl_directory.c:724)
==20538==    by 0x869E39: zim_spl_RecursiveDirectoryIterator___construct (spl_directory.c:1563)
==20538==    by 0xCE6370: zend_call_function (zend_execute_API.c:879)
==20538==    by 0xE0662A: zend_call_method (zend_interfaces.c:104)
==20538==    by 0x779BC1: zim_Phar___construct (phar_object.c:1233)
==20538==    by 0x101447C: ZEND_DO_FCALL_SPEC_HANDLER (zend_vm_execute.h:842)
==20538==  Address 0x73752f2e20656c75 is not stack'd, malloc'd or (recently) free'd
==20538== 
==20538== 
==20538== Process terminating with default action of signal 11 (SIGSEGV)
==20538==  General Protection Fault
==20538==    at 0xC70678: zend_mm_alloc_small (zend_alloc.c:1291)
==20538==    by 0xC70678: zend_mm_alloc_heap (zend_alloc.c:1358)
==20538==    by 0xC70678: _emalloc (zend_alloc.c:2442)
==20538==    by 0xC7696F: _estrndup (zend_alloc.c:2565)
==20538==    by 0x76BD95: phar_split_fname (phar.c:2229)
==20538==    by 0x732F19: phar_parse_url (stream.c:74)
==20538==    by 0x747A26: phar_wrapper_open_dir (dirstream.c:315)
==20538==    by 0xBA6BB7: _php_stream_opendir (streams.c:1982)
==20538==    by 0x85DDB2: spl_filesystem_dir_open (spl_directory.c:236)
==20538==    by 0x869E39: spl_filesystem_object_construct (spl_directory.c:724)
==20538==    by 0x869E39: zim_spl_RecursiveDirectoryIterator___construct (spl_directory.c:1563)
==20538==    by 0xCE6370: zend_call_function (zend_execute_API.c:879)
==20538==    by 0xE0662A: zend_call_method (zend_interfaces.c:104)
==20538==    by 0x779BC1: zim_Phar___construct (phar_object.c:1233)
==20538==    by 0x101447C: ZEND_DO_FCALL_SPEC_HANDLER (zend_vm_execute.h:842)

...

Looks like the source of the issue is in phar_analyze_path, namely in this code:

				if (!(realpath = expand_filepath(filename, NULL))) {
					efree(filename);
					return FAILURE;
				}
#ifdef PHP_WIN32
				phar_unixify_path_separators(realpath, strlen(realpath));
#endif
				slash = strstr(realpath, filename);
				if (slash) {
					slash += ((ext - fname) + ext_len);
					*slash = '\0';
				}

The problem there is that if fname and thus filename contain \0's, which in this example they do, realpath of course would not contain those parts and thus slash would point past the end of the realpath buffer. I think the best solution would be to just reject filenames that contain \0 outright.

Not sure if it's a security issue though as for this to be exploitable the application should allow attacker to create phar files with arbitrary filenames - which pretty much already means full disk access.

happens also in 5.x

Fix in security repo as 1e9b175204e3286d64dfd6c9f09151c31b5e099a for 7.0, 72281f29dd4691b2f741362d3581162fcf85f502 for 5.5

Also in https://gist.github.com/smalyshev/80b5c2909832872f2ba2
Please verify

ok, fixed

attacking vector without local cli  

<?php

$uploaddir = '/var/www/uploads/';
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);

if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {
		$testfile = file_get_contents($uploadfile);
	try {
		$phar = new Phar($testfile);
		$phar['index.php'] = '<?php echo "https://twitter.com/vah_13"; ?>';
		$phar['index.phps'] = '<?php echo "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"; ?>';
		$phar->setStub('<?php
	Phar::webPhar();
	__HALT_COMPILER(); ?>');
	} catch (Exception $e) {
			print $e;
	}
}

?>

here is video 

https://drive.google.com/file/d/0B7gu5bbuZn2ITk54ZGl5SzVWNlk/view?usp=sharing

rash have in new Phar($file) function.

code execution can create, see this doc 

https://www.exploit-db.com/docs/33698.pdf (0x04 Control RIP)

Of course any CLI script can be converted to one run through the web, that isn't what distinguishes security issues. Anyway, since it has to do with phar filenames and it is possible that at least part of can come from outside, for now I'm treating it as security issue just to be cautious.

okay.
commit & merged? :-)

Not merged yet. Security issues are merged at release time - which is next week.