php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74308 Memory corruption in gmp_powm
Submitted: 2017-03-24 10:34 UTC Modified: 2017-08-12 01:07 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: whitehat002 at hotmail dot com Assigned:
Status: Wont fix Package: GNU MP related
PHP Version: 7.1.3 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
35 - 35 = ?
Subscribe to this entry?

 
 [2017-03-24 10:34 UTC] whitehat002 at hotmail dot com
Description:
------------
I found it via Black-box Testing.It looks like the libgmp's problem.And I think it's a security bug for memory corruption.
My test environment:
root@mhn:~# /usr/local/php/bin/php -v
PHP 7.1.3 (cli) (built: Mar 24 2017 13:29:12) ( ZTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies

And gmp's version is 6.1.2.

Test script:
---------------
<?php
ini_set('memory_limit',-1);
$a=str_repeat("1",0x80000000);

var_dump(gmp_powm("1",$a ,200));

?>

Expected result:
----------------
no crash

Actual result:
--------------
root@mhn:~# gdb --q --args ./php-7.1.3/sapi/cli/php -n test.php
Reading symbols from ./php-7.1.3/sapi/cli/php...done.
(gdb) r
Starting program: /root/php-7.1.3/sapi/cli/php -n test.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
GNU MP: Cannot allocate memory (size=2147483665)

Program received signal SIGABRT, Aborted.
0x00007ffff5720c37 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff5720c37 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff5724028 in __GI_abort () at abort.c:89
#2  0x00007ffff75072a5 in __gmp_default_allocate ()
   from /usr/lib/x86_64-linux-gnu/libgmp.so.10
#3  0x00007ffff7507b89 in __gmp_tmp_reentrant_alloc ()
   from /usr/lib/x86_64-linux-gnu/libgmp.so.10
#4  0x00007ffff751d76f in __gmpz_set_str () from /usr/lib/x86_64-linux-gnu/libgmp.so.10
#5  0x00000000005e9ada in convert_to_gmp (gmpnumber=0x7fffffffad50, 
    val=<optimized out>, base=<optimized out>) at /root/php-7.1.3/ext/gmp/gmp.c:738
#6  0x00000000005ec6af in zif_gmp_powm (execute_data=<optimized out>, 
    return_value=0x7ffff12130c0) at /root/php-7.1.3/ext/gmp/gmp.c:1427
#7  0x00000000008bcfb7 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER ()
    at /root/php-7.1.3/Zend/zend_vm_execute.h:675
#8  0x00000000008abe73 in execute_ex (ex=<optimized out>)
    at /root/php-7.1.3/Zend/zend_vm_execute.h:429
#9  0x0000000000907edb in zend_execute (op_array=<optimized out>, 
    return_value=<optimized out>) at /root/php-7.1.3/Zend/zend_vm_execute.h:474
#10 0x0000000000861d47 in zend_execute_scripts (type=type@entry=8, 
    retval=retval@entry=0x0, file_count=file_count@entry=3)
    at /root/php-7.1.3/Zend/zend.c:1476
#11 0x00000000007f2010 in php_execute_script (
    primary_file=primary_file@entry=0x7fffffffd290) at /root/php-7.1.3/main/main.c:2537
#12 0x000000000090a355 in do_cli (argc=3, argv=0x11f8a30)
    at /root/php-7.1.3/sapi/cli/php_cli.c:993
#13 0x0000000000440d3a in main (argc=3, argv=0x11f8a30)
---Type <return> to continue, or q <return> to quit---
    at /root/php-7.1.3/sapi/cli/php_cli.c:1381

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-03-25 04:31 UTC] whitehat002 at hotmail dot com
Most of functions for GNU Mp related have the same problem.
 [2017-03-25 11:36 UTC] whitehat002 at hotmail dot com
Take this function (gmp_scan0) as an example
test script
<?php
ini_set('memory_limit',-1);
$a=str_repeat("1",0xffffffff);
gmp_scan0($a,0xffffffff);
--------------------------------------------------------
crash information:
root@mhn:~# /usr/local/php/bin/php test.php 
GNU MP: Cannot allocate memory (size=4294967312)
Aborted (core dumped)
--------------------------------------------------------
root@mhn:~# gdb -q --args ./php-7.1.3/sapi/cli/php -n test.php
Reading symbols from ./php-7.1.3/sapi/cli/php...done.
(gdb) r
Starting program: /root/php-7.1.3/sapi/cli/php -n test.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
GNU MP: Cannot allocate memory (size=4294967312)

Program received signal SIGABRT, Aborted.
0x00007ffff5720c37 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff5720c37 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff5724028 in __GI_abort () at abort.c:89
#2  0x00007ffff75072a5 in __gmp_default_allocate ()
   from /usr/lib/x86_64-linux-gnu/libgmp.so.10
#3  0x00007ffff7507b89 in __gmp_tmp_reentrant_alloc ()
   from /usr/lib/x86_64-linux-gnu/libgmp.so.10
#4  0x00007ffff751d76f in __gmpz_set_str () from /usr/lib/x86_64-linux-gnu/libgmp.so.10
#5  0x00000000005e9ada in convert_to_gmp (gmpnumber=0x7fffffffad70, 
    val=<optimized out>, base=<optimized out>) at /root/php-7.1.3/ext/gmp/gmp.c:738
#6  0x00000000005ea4c8 in zif_gmp_scan0 (execute_data=<optimized out>, 
    return_value=0x7fffffffadc0) at /root/php-7.1.3/ext/gmp/gmp.c:2050
#7  0x00000000008bd1bd in ZEND_DO_ICALL_SPEC_RETVAL_UNUSED_HANDLER ()
    at /root/php-7.1.3/Zend/zend_vm_execute.h:628
#8  0x00000000008abe73 in execute_ex (ex=<optimized out>)
    at /root/php-7.1.3/Zend/zend_vm_execute.h:429
#9  0x0000000000907edb in zend_execute (op_array=<optimized out>, 
    return_value=<optimized out>) at /root/php-7.1.3/Zend/zend_vm_execute.h:474
#10 0x0000000000861d47 in zend_execute_scripts (type=type@entry=8, 
    retval=retval@entry=0x0, file_count=file_count@entry=3)
    at /root/php-7.1.3/Zend/zend.c:1476
#11 0x00000000007f2010 in php_execute_script (
    primary_file=primary_file@entry=0x7fffffffd290) at /root/php-7.1.3/main/main.c:2537
#12 0x000000000090a355 in do_cli (argc=3, argv=0x11f8a30)
    at /root/php-7.1.3/sapi/cli/php_cli.c:993
#13 0x0000000000440d3a in main (argc=3, argv=0x11f8a30)
---Type <return> to continue, or q <return> to quit---
    at /root/php-7.1.3/sapi/cli/php_cli.c:1381
 [2017-03-26 20:59 UTC] stas@php.net
-Type: Security +Type: Bug
 [2017-03-28 11:04 UTC] whitehat002 at hotmail dot com
Is there anyone dealing with the problem?
 [2017-03-28 12:09 UTC] nikic@php.net
I don't think we're going to fix OOM issues in GMP. It is not possible for us to replace the GMP allocator functions due to conflicts with other libraries using GMP (we used to do this, it does not work robustly).

There is no security issue here, because GMP safely aborts in case of an OOM condition. The only attack vector here is denial of service. However, if you allow attacker-controlled, unbounded allocations you have a DOS vector regardless of GMPs OOM behavior.
 [2017-03-28 12:23 UTC] whitehat002 at hotmail dot com
I venture to ask who should deal with the problem.
 [2017-08-12 01:07 UTC] ajf@php.net
-Status: Open +Status: Wont fix
 [2017-08-12 01:07 UTC] ajf@php.net
Fixing OOM issues for GMP is essentially a “wouldn't it be nice” thing. Unless and until GMP is baked into the core language as a data type, rather than an optional extension, it's probably not going to be fixed.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 22:01:26 2024 UTC