php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #75934 Out of Bound in sodium_pad
Submitted: 2018-02-08 07:11 UTC Modified: 2021-07-21 13:41 UTC
Votes:4
Avg. Score:3.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:3 (100.0%)
From: zhihua dot yao at dbappsecurity dot com dot cn Assigned: jedisct1 (profile)
Status: Assigned Package: Reproducible crash
PHP Version: 7.2.2 OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: zhihua dot yao at dbappsecurity dot com dot cn
New email:
PHP Version: OS:

 

 [2018-02-08 07:11 UTC] zhihua dot yao at dbappsecurity dot com dot cn 
Description:
------------
I do not know where the problem is.

Test script:
---------------
<?php
ini_set('memory_limit',-1);
$str=str_repeat("A",0x7fffffff);
sodium_pad($str,0x7fffffff);


Actual result:
--------------
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x08253de4 in zif_sodium_pad (execute_data=0xb781a0a0, 
    return_value=0xbfffbbf0)
    at /home/hjy/Desktop/php-7.2.2/ext/sodium/libsodium.c:3406
3406			ZSTR_VAL(padded)[j] = unpadded[i];
gdb-peda$ bt
#0  0x08253de4 in zif_sodium_pad (execute_data=0xb781a0a0, 
    return_value=0xbfffbbf0)
    at /home/hjy/Desktop/php-7.2.2/ext/sodium/libsodium.c:3406
#1  0x083f7d04 in ZEND_DO_ICALL_SPEC_RETVAL_UNUSED_HANDLER ()
    at /home/hjy/Desktop/php-7.2.2/Zend/zend_vm_execute.h:573
#2  execute_ex (ex=0x37400010)
    at /home/hjy/Desktop/php-7.2.2/Zend/zend_vm_execute.h:59731
#3  0x084002b4 in zend_execute (op_array=op_array@entry=0xb787c000, 
    return_value=return_value@entry=0x0)
    at /home/hjy/Desktop/php-7.2.2/Zend/zend_vm_execute.h:63760
#4  0x08363690 in zend_execute_scripts (type=type@entry=0x8, 
    retval=retval@entry=0x0, file_count=file_count@entry=0x3)
    at /home/hjy/Desktop/php-7.2.2/Zend/zend.c:1496
#5  0x0830344e in php_execute_script (
    primary_file=primary_file@entry=0xbfffdee4)
    at /home/hjy/Desktop/php-7.2.2/main/main.c:2590
#6  0x084026db in do_cli (argc=argc@entry=0x2, 
    argv=argv@entry=0x8af8000)
    at /home/hjy/Desktop/php-7.2.2/sapi/cli/php_cli.c:1011
#7  0x08071637 in main (argc=0x2, argv=0x8af8000)
    at /home/hjy/Desktop/php-7.2.2/sapi/cli/php_cli.c:1404
#8  0xb7c08af3 in __libc_start_main (main=0x8071160 <main>, argc=0x2, 
    argv=0xbffff194, init=0x840a390 <__libc_csu_init>, 
    fini=0x840a400 <__libc_csu_fini>, rtld_fini=0xb7fed2d0 <_dl_fini>, 
    stack_end=0xbffff18c) at libc-start.c:287
#9  0x080716c2 in _start ()

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-04-27 02:41 UTC] zhihua dot yao at dbappsecurity dot com dot cn 
Any update?Security Issue?
 [2018-04-27 12:05 UTC] cmb@php.net
-Assigned To: +Assigned To: jedisct1
 [2018-04-27 12:05 UTC] cmb@php.net 
On a quick glance, the check `blocksize > SIZE_MAX`[1] looks
fishy. Frank, could you please have a look at this issue?

[1] <https://github.com/php/php-src/blob/PHP-7.2.2/ext/sodium/libsodium.c#L3386>
 [2018-04-27 13:43 UTC] jedisct1@php.net 
What system is that on? Is it a 32 bit system?
 [2018-04-27 14:26 UTC] zhihua dot yao at dbappsecurity dot com dot cn 
Yes,Ubuntu 14.04 x86
 [2018-04-27 14:34 UTC] jedisct1@php.net 
Weird, the memory allocation should have failed. There are no ways to allocate close to 4 Gb on Linux/i386.

Tried on a Linux system and the memory allocation failed as expected.

Where did you find a PHP 7 binary for such an old distribution?
 [2018-04-28 00:52 UTC] zhihua dot yao at dbappsecurity dot com dot cn 
However, I was using the latest version. When I compiled the sodium, this poc would cause a crash.Maybe it has been fixed?
 [2018-04-28 14:13 UTC] jedisct1@php.net 
zend_string_alloc() is broken due to the absence of overflow check before rounding; if the requested length is >= SIZE_MAX-16, it allocates either 0 or 16 bytes, and returns a valid pointer instead of an OOM.
 [2018-04-28 14:37 UTC] jedisct1@php.net 
Workaround: https://github.com/jedisct1/libsodium-php/commit/75701f246f44911ca9cd559341c827538f563d24

But the root cause should rather be fixed.
 [2018-04-29 12:57 UTC] zhihua dot yao at dbappsecurity dot com dot cn 
Okay, is this a security issue?I really do not understand the classification of your security issues. Some of them I believe are not classified as security issues,but classified as security issues.
 [2018-04-29 17:30 UTC] jedisct1@php.net 
I'd consider this a security issue. Which is trivial to trigger:

ini_set('memory_limit',-1);
$a = str_repeat('x', 2147483647);
$b = $a . $a;
 [2018-04-29 17:33 UTC] jedisct1@php.net 
This can be downplayed by pointing out the fact that `ini_set('memory_limit',-1);` is not a thing to allow on untrusted data/scripts. 

But altering the memory_limit value may not be required to trigger this overflow.
 [2018-04-29 17:36 UTC] spam2 at rhsoft dot net 
sadly the php-developers typically don't consider something which needs to be triggered with code like yours or whatever triggers a OOM as security issue

there are many bug reports in the recent past "just verify your input" classified
 [2018-04-29 18:23 UTC] spam2 at rhsoft dot net 
https://wiki.php.net/security

We do not classify as a security issue any issue that:

requires invocation of specific code, which may be valid but is obviously malicious

requires invocation of functions with specific arguments, which may be valid but are obviously malicious

requires specific actions to be performed on the server, which are not commonly performed, or are not commonly permissible for the user (uid) executing PHP

requires privileges superior to that of the user (uid) executing PHP

requires the use of debugging facilities - ex. xdebug, var_dump

requires the use of settings not recommended for production - ex. error reporting to output

requires the use of non-standard environment variables - ex. USE_ZEND_ALLOC

requires the use of non-standard builds - ex. obscure embedded platform, not commonly used compiler

requires the use of code or settings known to be insecure
 [2018-04-30 06:23 UTC] zhihua dot yao at dbappsecurity dot com dot cn 
Yes, @spam2.rhsoft.net,In the past, this should be classified as a security issue
 [2021-07-21 13:41 UTC] cmb@php.net 
@jedisct1, please see the closely related PR #7252[1], especially
Dmitry's comment near the end, and the follow up solution PR
#7294[2].

TL;DR: use ZSTR_MAX_LEN instead of SIZE_MAX.

[1] <https://github.com/php/php-src/pull/7252>
[2] <https://github.com/php/php-src/pull/7294>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 16:01:29 2024 UTC