php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Sec Bug #68618 out of bounds read crashes php-cgi
Submitted: 2014-12-17 21:24 UTC Modified: 2015-01-20 20:00 UTC
From: brian dot carpenter at gmail dot com Assigned: stas (profile)
Status: Closed Package: Reproducible crash
PHP Version: master-Git-2014-12-17 (Git) OS: Debian 7
Private report: No CVE-ID: 2014-9427
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: brian dot carpenter at gmail dot com
New email:
PHP Version: OS:

 

 [2014-12-17 21:24 UTC] brian dot carpenter at gmail dot com
Description:
------------
I cloned the php git repo on 12/16/2014 and built from source using the afl-gcc compiler:

CC=/path/to/afl-gcc ./configure
AFL_HARDEN=1 make

PHP 7.0.0-dev (cgi-fcgi) (built: Dec 16 2014 14:07:45)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2014 Zend Technologies

While fuzzing the php-cgi binary, I found that a one byte file containing # and no newline causes php-cgi to segfault. 

printf "#" >crashme.php
./php-cgi crashme.php
Segmentation fault

I talked with the author of afl-fuzz to make sure there wasn't some pointer weirdness happening as a result of compiling this with afl-gcc and he says it looks like an out of bounds read, probably not exploitable, but might could disclose server memory, but anyone that can upload php scripts can do far worse. 

I have not tried exploiting this via a browser with XSS or anything fancy yet, just passing this via the command line in a Debian VM. I can provide a core dump or any other information that is needed.

Expected result:
----------------
php-cgi should fail gracefully, not segfault.

Actual result:
--------------
==61759== Invalid read of size 1
==61759==    at 0x4575B0: main (cgi_main.c:2460)
==61759==  Address 0x4024000 is not stack'd, malloc'd or (recently) free'd
==61759== 
==61759== 
==61759== Process terminating with default action of signal 11 (SIGSEGV)
==61759==  Access not within mapped region at address 0x4024000
==61759==    at 0x4575B0: main (cgi_main.c:2460)
==61759==  If you believe this happened as a result of a stack
==61759==  overflow in your program's main thread (unlikely but
==61759==  possible), you can try to increase the size of the
==61759==  main thread stack using the --main-stacksize= flag.
==61759==  The main thread stack size used in this run was 8388608.
Segmentation fault

Patches

68618a (last revision 2021-06-04 15:39 UTC by 10615713 at qq dot com)

Add a Patch

Pull Requests

Pull requests:

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-12-17 21:39 UTC] brian dot carpenter at gmail dot com
PHP 5.4.35-0+deb7u2 (cgi-fcgi) (built: Nov 19 2014 07:58:17) is also susceptible to this crash.
 [2014-12-17 21:44 UTC] brian dot carpenter at gmail dot com
-Type: Bug +Type: Security -Private report: No +Private report: Yes
 [2014-12-17 21:44 UTC] brian dot carpenter at gmail dot com
Changing this to a security bug until someone smarter than me can take a look at mark it otherwise.
 [2014-12-18 08:06 UTC] remi@php.net
Reproduced with 5.6.4:

(gdb) bt
#0  0x00007ffff4be76ba in memchr () from /lib64/libc.so.6
#1  0x000055555575bec0 in lex_scan (zendlval=zendlval@entry=0x7fffffff8f68) at Zend/zend_language_scanner.l:1757
#2  0x000055555577b982 in zendlex (zendlval=zendlval@entry=0x7fffffff8f60) at /usr/src/debug/php-5.6.4/Zend/zend_compile.c:6875
#3  0x0000555555755a3e in zendparse () at /usr/src/debug/php-5.6.4/Zend/zend_language_parser.c:3732
#4  0x000055555575b275 in compile_file (file_handle=file_handle@entry=0x7fffffffd7d0, type=8) at Zend/zend_language_scanner.l:586
#5  0x000055555578231a in dtrace_compile_file (file_handle=0x7fffffffd7d0, type=<optimized out>) at /usr/src/debug/php-5.6.4/Zend/zend_dtrace.c:40
#6  0x0000555555794d1f in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3)
    at /usr/src/debug/php-5.6.4/Zend/zend.c:1336
#7  0x0000555555730c9b in php_execute_script (primary_file=0x7fffffffd7d0) at /usr/src/debug/php-5.6.4/main/main.c:2584
#8  0x0000555555611c0f in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/php-5.6.4/sapi/cgi/cgi_main.c:2457
 [2014-12-18 09:00 UTC] brian dot carpenter at gmail dot com
Seeing something slightly different with 7.0.0-dev:

(gdb) bt
#0  memchr () at ../sysdeps/x86_64/memchr.S:46
#1  0x00000000013c083b in lex_scan (zendlval=0x7fffbb981880)
    at Zend/zend_language_scanner.l:1641
#2  0x0000000001462ec8 in zendlex (elem=0x7fffbb981920)
    at /home/geeknik/php-src/Zend/zend_compile.c:1335
#3  0x000000000139dacf in zendparse ()
    at /home/geeknik/php-src/Zend/zend_language_parser.c:4408
#4  0x00000000013a9cad in compile_file (file_handle=0x7fffbb9849b0, type=8)
    at Zend/zend_language_scanner.l:585
#5  0x0000000000eca498 in phar_compile_file (file_handle=0x7fffbb9849b0, type=8)
    at /home/geeknik/php-src/ext/phar/phar.c:3311
#6  0x0000000001517ca8 in zend_execute_scripts (type=8, retval=0x0, 
    file_count=3) at /home/geeknik/php-src/Zend/zend.c:1257
#7  0x00000000012ddfc2 in php_execute_script (primary_file=0x7fffbb9849b0)
    at /home/geeknik/php-src/main/main.c:2563
#8  0x0000000000455425 in main (argc=2, argv=0x7fffbb984d68)
    at /home/geeknik/php-src/sapi/cgi/cgi_main.c:2478
#9  0x00007f123f7b1ead in __libc_start_main (main=<optimized out>, 
    argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffbb984d58)
    at libc-start.c:244
#10 0x000000000045b33d in _start ()
 [2014-12-30 09:30 UTC] stas@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: stas
 [2014-12-30 09:30 UTC] stas@php.net
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.


 [2015-01-20 20:00 UTC] stas@php.net
-CVE-ID: +CVE-ID: 2014-9427
 [2021-06-04 15:39 UTC] 10615713 at qq dot com
The following patch has been added/updated:

Patch Name: 68618a
Revision:   1622821171
URL:        https://bugs.php.net/patch-display.php?bug=68618&patch=68618a&revision=1622821171
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 09:01:28 2024 UTC