Project: php-src (php/php-src), language: c++
Vulnerability instance: php.cve-2019-9021
Sanitizer: address

================= Bug Report (1/1) ==================
## Source: PHP Bugs
## URL: https://bugs.php.net/bug.php?id=77247
## Description:
PHP Bug ID: 77247
Summary: heap buffer overflow in phar_detect_phar_fname_ext
Status: Closed
PHP Version: 5.6.39
Assigned: stas (profile)
CVE-ID: 2019-9021

Description:
Description:
------------
I used afl to find another problem, but it is not the same as the #77143 issue.


$ uname -a
Linux hackyzh-virtual-machine 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
hackyzh@hackyzh-virtual-machine:~/Desktop$ ./php-src-PHP-7.2.13/sapi/cli/php -v
PHP 7.2.13-dev (cli) (built: Dec  6 2018 11:32:57) ( NTS DEBUG )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies


Test script:
---------------
USE_ZEND_ALLOC=0 ./php-src-PHP-7.2.13/sapi/cli/php -r "var_dump(new Phar(file_get_contents('poc.phar'),0,'test.phar'));"

Actual result:
--------------
$ USE_ZEND_ALLOC=0 ./php-src-PHP-7.2.13/sapi/cli/php -r "var_dump(new Phar(file_get_contents('poc.phar'),0,'test.phar'));"
=================================================================
==44888==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60600001bf60 at pc 0x7f17ca1cf935 bp 0x7ffc7b01ac20 sp 0x7ffc7b01a3c8
READ of size 26 at 0x60600001bf60 thread T0
    #0 0x7f17ca1cf934  (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x3e934)
    #1 0xf81430 in phar_detect_phar_fname_ext /home/hackyzh/Desktop/php-src-PHP-7.2.13/ext/phar/phar.c:2011
    #2 0xf8479c in phar_split_fname /home/hackyzh/Desktop/php-src-PHP-7.2.13/ext/phar/phar.c:2218
    #3 0xfc279e in zim_Phar___construct /home/hackyzh/Desktop/php-src-PHP-7.2.13/ext/phar/phar_object.c:1178
    #4 0x223908e in ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER /home/hackyzh/Desktop/php-src-PHP-7.2.13/Zend/zend_vm_execute.h:907
    #5 0x223c022 in execute_ex /home/hackyzh/Desktop/php-src-PHP-7.2.13/Zend/zend_vm_execute.h:59765
    #6 0x2280678 in zend_execute /home/hackyzh/Desktop/php-src-PHP-7.2.13/Zend/zend_vm_execute.h:63776
    #7 0x1c4dc40 in zend_eval_stringl /home/hackyzh/Desktop/php-src-PHP-7.2.13/Zend/zend_execute_API.c:1083
    #8 0x1c4e1c0 in zend_eval_stringl_ex /home/hackyzh/Desktop/php-src-PHP-7.2.13/Zend/zend_execute_API.c:1124
    #9 0x228d5bf in do_cli /home/hackyzh/Desktop/php-src-PHP-7.2.13/sapi/cli/php_cli.c:1042
    #10 0x472cc9 in main /home/hackyzh/Desktop/php-src-PHP-7.2.13/sapi/cli/php_cli.c:1403
    #11 0x7f17c810c82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #12 0x473308 in _start (/home/hackyzh/Desktop/php-src-PHP-7.2.13/sapi/cli/php+0x473308)

0x60600001bf60 is located 0 bytes to the right of 64-byte region [0x60600001bf20,0x60600001bf60)
allocated by thread T0 here:
    #0 0x7f17ca229961 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98961)
    #1 0x1b688c0 in __zend_realloc /home/hackyzh/Desktop/php-src-PHP-7.2.13/Zend/zend_alloc.c:2845

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x0c0c7fffb790: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fffb7a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fffb7b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fffb7c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fffb7d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c0c7fffb7e0: fa fa fa fa 00 00 00 00 00 00 00 00[fa]fa fa fa
  0x0c0c7fffb7f0: 00 00 00 00 00 00 00 06 fa fa fa fa 00 00 00 00
  0x0c0c7fffb800: 00 00 06 fa fa fa fa fa 00 00 00 00 00 00 00 fa
  0x0c0c7fffb810: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa
  0x0c0c7fffb820: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
  0x0c0c7fffb830: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==44888==ABORTING

Comments:

[Comment 1] [2018-12-06 08:13 UTC] zhihua dot yao at dbappsecurity dot com dot cn
poc link:
https://github.com/whiteHat001/FUZZ_POC/blob/master/poc.phar
Links: https://github.com/whiteHat001/FUZZ_POC/blob/master/poc.phar

[Comment 2] [2018-12-06 08:20 UTC] zhihua dot yao at dbappsecurity dot com dot cn
Or curl http://144.202.86.156/poc.phar -o poc.phar
Links: http://144.202.86.156/poc.phar

[Comment 3] [2018-12-07 11:05 UTC] zhihua dot yao at dbappsecurity dot com dot cn
Hi,
Any response?

[Comment 4] [2018-12-11 11:40 UTC] zhihua dot yao at dbappsecurity dot com dot cn
My vps is broken.use this url http://149.28.200.107/poc.tar.gz
Links: http://149.28.200.107/poc.tar.gz

[Comment 5] [2018-12-16 01:00 UTC] stas@php.net
From what I understand, the problem is when supplying invalid filename to Phar extension. However, I could not reproduce any issue there: all I get is:

PHP Fatal error:  Uncaught exception 'UnexpectedValueException' with message 'Cannot create phar 'DDDDDDDDDDDDD/.DDDDDDDDDDDdDDDDD_DDDDDD', file extension (or combination) not recognised or the directory does not exist' in Command line code:1
Stack trace:
#0 Command line code(1): Phar->__construct('DDDDDDDDDDDDD/....', 0, 'test.phar')
#1 {main}
  thrown in Command line code on line 1

Am I using a wrong file?

[Comment 6] [2018-12-16 07:44 UTC] zhihua dot yao at dbappsecurity dot com dot cn
Did you use the poc at this address, http://149.28.200.107/poc.tar.gz
The link https://github.com/whiteHat001/FUZZ_POC/blob/master/poc.phar is error
Links: http://149.28.200.107/poc.tar.gz, https://github.com/whiteHat001/FUZZ_POC/blob/master/poc.phar

[Comment 7] [2018-12-16 07:47 UTC] zhihua dot yao at dbappsecurity dot com dot cn
stats,you can use id/000000,sig/06,src/000117,op/havoc,rep/4 or other files.

[Comment 8] [2018-12-24 11:40 UTC] zhihua dot yao at dbappsecurity dot com dot cn
So can you reproduce this security issue?

[Comment 9] [2018-12-25 07:02 UTC] stas@php.net
No, I could not reproduce any issue, I just get an error message as described above.

[Comment 10] [2018-12-25 07:30 UTC] zhihua dot yao at dbappsecurity dot com dot cn
Which php version are you using, or are you using USE_ZEND_ALLOC=0?

[Comment 11] [2018-12-25 08:09 UTC] zhihua dot yao at dbappsecurity dot com dot cn
I think I found the reason, you did not use USE_ZEND_ALLOC=0 options

[Comment 12] [2018-12-26 00:59 UTC] cmb@php.net
The following patch has been added/updated:

Patch Name: 77247
Revision:   1545785942
URL:        https://bugs.php.net/patch-display.php?bug=77247&patch=77247&revision=1545785942
Links: https://bugs.php.net/patch-display.php?bug=77247&patch=77247&revision=1545785942

[Comment 13] [2018-12-26 00:59 UTC] cmb@php.net
I can confirm OOB reads, even with a much simpler reproducer:

    new Phar('a/.b');

It seems there is a sign confusion regarding a memchr()[1] (the
minus should be a plus).  Could you please try with the attached
77247.patch?

[1] <https://github.com/php/php-src/blob/php-7.3.0/ext/phar/phar.c#L2029>
Links: https://github.com/php/php-src/blob/php-7.3.0/ext/phar/phar.c#L2029

[Comment 14] [2018-12-26 01:02 UTC] cmb@php.net
> (the minus should be a plus)

Oops, of course, the other way round.

[Comment 15] [2018-12-26 02:02 UTC] zhihua dot yao at dbappsecurity dot com dot cn
Has it been patched？Why do I see that the patch is no different from the original code?

[Comment 16] [2018-12-26 09:51 UTC] cmb@php.net
See <https://gist.github.com/cmb69/2a2c1e3cdcd3a6b8616e1b00e7c19bc5>.
Links: https://gist.github.com/cmb69/2a2c1e3cdcd3a6b8616e1b00e7c19bc5

[Comment 17] [2018-12-26 10:14 UTC] zhihua dot yao at dbappsecurity dot com dot cn
It looks like that has been fixed.I can't reproduce.

[Comment 18] [2018-12-29 02:54 UTC] zhihua dot yao at dbappsecurity dot com dot cn
Could you apply for cve for this issue?

[Comment 19] [2018-12-30 02:29 UTC] stas@php.net
For some reason, on my build AddressSanitizer fails to complain about it (yes, with USE_ZEND_ALLOC=0 too - maybe some optimization effect?) but tracing it manually I see memchr argument too large. 

Added patch to security repo as fd7a753db928db9c8b65d0fc37df08b40d846a4c

[Comment 30] [2019-02-16 14:04 UTC] zhihua dot yao at dbappsecurity dot com dot cn
Can I ask the number of this cve? I need to use this cve for some use.

Commit References:
fd7a753db928db9c8b65d0fc37df08b40d846a4c

Build script:
#!/bin/bash -eu
# Minimized build script with only core build commands
set -eu
./buildconf --force
./configure \
        --enable-option-checking=fatal \
        --disable-libxml \
        --disable-dom \
        --disable-simplexml \
        --disable-xml \
        --disable-xmlreader \
        --disable-xmlwriter \
        --without-pear \
        --enable-exif \
        --disable-phpdbg \
        --disable-cgi
make -j$(nproc)

Dockerfile:
FROM hwiwonlee/secb.base:latest
RUN apt-get update && apt-get install -y make autoconf automake libtool bison re2c make ca-certificates curl xz-utils dpkg-dev file libc-dev pkg-config libcurl4-openssl-dev libedit-dev libsqlite3-dev libssl-dev zlib1g-dev
RUN git clone https://github.com/php/php-src php-src
RUN git -C php-src checkout 05fb10165081cb4fb55a9943b44cab62c627db7a
WORKDIR $SRC/php-src
COPY build.sh $SRC/

Additional files: