|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75934 Out of Bound in sodium_pad
Submitted: 2018-02-08 07:11 UTC Modified: 2021-07-21 13:41 UTC
Avg. Score:3.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (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 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.
Block user comment
Status: Assign to:
Bug Type:
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
I do not know where the problem is.

Test script:

Actual result:
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x08253de4 in zif_sodium_pad (execute_data=0xb781a0a0, 
    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, 
    at /home/hjy/Desktop/php-7.2.2/ext/sodium/libsodium.c:3406
    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, 
    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 (
    at /home/hjy/Desktop/php-7.2.2/main/main.c:2590
#6  0x084026db in do_cli (argc=argc@entry=0x2, 
    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 ()


Add a Patch

Pull Requests

Add a Pull Request


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]
-Assigned To: +Assigned To: jedisct1
 [2018-04-27 12:05 UTC]
On a quick glance, the check `blocksize > SIZE_MAX`[1] looks
fishy. Frank, could you please have a look at this issue?

[1] <>
 [2018-04-27 13:43 UTC]
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]
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]
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]

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]
I'd consider this a security issue. Which is trivial to trigger:

$a = str_repeat('x', 2147483647);
$b = $a . $a;
 [2018-04-29 17:33 UTC]
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

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,,In the past, this should be classified as a security issue
 [2021-07-21 13:41 UTC]
@jedisct1, please see the closely related PR #7252[1], especially
Dmitry's comment near the end, and the follow up solution PR

TL;DR: use ZSTR_MAX_LEN instead of SIZE_MAX.

[1] <>
[2] <>
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Apr 22 04:01:31 2024 UTC