php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68095 AddressSanitizer reports a heap buffer overflow in php_getopt()
Submitted: 2014-09-25 08:04 UTC Modified: 2014-09-30 00:27 UTC
From: symeon dot paraschoudis at htbridge dot com Assigned:
Status: Closed Package: *General Issues
PHP Version: 5.5.17 OS: Ubuntu 14.04.1 LTS 32bit
Private report: No CVE-ID: None
 [2014-09-25 08:04 UTC] symeon dot paraschoudis at htbridge dot com
Description:
------------
It also affects 5.6.0
Please note I was not able to reproduce it on a Windows system.

PoC
===============================

php -c -i -ini

Result
===============================

=================================================================
==19849== ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb2900613 at pc 0x8e7c77e bp 0xbfdeb138 sp 0xbfdeb12c
READ of size 1 at 0xb2900613 thread T0
    #0 0x8e7c77d in php_getopt getopt.c:135
    #1 0x92c38a6 in do_cli php_cli.c:682 (discriminator 1)
    #2 0x92c7c1d in main php_cli.c:1378
    #3 0xb504ca82 in __libc_start_main libc-start.c:287
    #4 0x807be20 in _start ??:?
0xb2900613 is located 0 bytes to the right of 3-byte region [0xb2900610,0xb2900613)
allocated by thread T0 here:
    #0 0xb6147854 in malloc ??:?
    #1 0xb50ae257 in __GI___strdup strdup.c:42
    #2 0x92e7ef7 in save_ps_args ps_title.c:222
    #3 0x92c66f6 in main php_cli.c:1225
    #4 0xb504ca82 in __libc_start_main libc-start.c:287
Shadow bytes around the buggy address:
  0x36520070: fa fa 00 01 fa fa 00 01 fa fa 00 fa fa fa 00 02
  0x36520080: fa fa 00 fa fa fa 00 fa fa fa 04 fa fa fa fd fd
  0x36520090: fa fa fd fd fa fa 00 00 fa fa fd fd fa fa fd fa
  0x365200a0: fa fa fd fa fa fa 03 fa fa fa fd fa fa fa 00 00
  0x365200b0: fa fa fd fd fa fa 04 fa fa fa 05 fa fa fa 03 fa
=>0x365200c0: fa fa[03]fa fa fa 04 fa fa fa 00 03 fa fa 00 02
  0x365200d0: fa fa 00 05 fa fa 00 07 fa fa 00 00 fa fa 00 07
  0x365200e0: fa fa 00 fa fa fa 00 07 fa fa 00 01 fa fa 00 02
  0x365200f0: fa fa 00 03 fa fa 00 00 fa fa 00 07 fa fa 00 03
  0x36520100: fa fa 00 fa fa fa 00 03 fa fa 00 07 fa fa 00 fa
  0x36520110: fa fa 00 fa fa fa fd fd fa fa 00 fa fa fa fd fd
==19849== ABORTING


or triggering it with valgrind:

$ valgrind --tool=memcheck --num-callers=30 --log-file=php.log ~/Desktop/php-5.5.17/sapi/cli/php -c -i -ini


user@ubuntuvm:~/Desktop$ cat php.log 
==19859== Memcheck, a memory error detector
==19859== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==19859== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==19859== Command: /home/user/Desktop/php-5.5.17/sapi/cli/php -c -i -ini
==19859== Parent PID: 2142
==19859== 
==19859== Invalid read of size 1
==19859==    at 0x856FA95: php_getopt (getopt.c:135)
==19859==    by 0x869D76D: do_cli (php_cli.c:682)
==19859==    by 0x869F278: main (php_cli.c:1378)
==19859==  Address 0x6ee709b is 0 bytes after a block of size 3 alloc'd
==19859==    at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==19859==    by 0x5000257: strdup (strdup.c:42)
==19859==    by 0x86A98F9: save_ps_args (ps_title.c:222)
==19859==    by 0x869EADE: main (php_cli.c:1225)
==19859== 
==19859== 
==19859== HEAP SUMMARY:
==19859==     in use at exit: 14,843 bytes in 30 blocks
==19859==   total heap usage: 34,740 allocs, 34,710 frees, 2,668,162 bytes allocated
==19859== 
==19859== LEAK SUMMARY:
==19859==    definitely lost: 0 bytes in 0 blocks
==19859==    indirectly lost: 0 bytes in 0 blocks
==19859==      possibly lost: 0 bytes in 0 blocks
==19859==    still reachable: 14,843 bytes in 30 blocks
==19859==         suppressed: 0 bytes in 0 blocks
==19859== Rerun with --leak-check=full to see details of leaked memory
==19859== 
==19859== For counts of detected and suppressed errors, rerun with: -v
==19859== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-09-30 00:27 UTC] stas@php.net
The problem here seems to be that php_getopt retains optchr between runs, even though they may relate to different option situations. So if somebody starts a php_optarg run and abandons it in the middle of options parsing, and then starts another one, optchr may be pointing at wrong place.
 [2014-10-28 02:11 UTC] stas@php.net
Automatic comment on behalf of stas
Revision: http://git.php.net/?p=php-src.git;a=commit;h=deadeeae1d08877021eb2796aa6790baa74361ed
Log: Fix bug #68095 - invalid read in php_getopt()
 [2014-10-28 02:11 UTC] stas@php.net
-Status: Open +Status: Closed
 [2014-11-18 20:34 UTC] ab@php.net
Automatic comment on behalf of stas
Revision: http://git.php.net/?p=php-src.git;a=commit;h=deadeeae1d08877021eb2796aa6790baa74361ed
Log: Fix bug #68095 - invalid read in php_getopt()
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 17:01:29 2024 UTC