go to bug id or search bugs for
I do not know where the problem is.
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x08253de4 in zif_sodium_pad (execute_data=0xb781a0a0,
3406 ZSTR_VAL(padded)[j] = unpadded[i];
#0 0x08253de4 in zif_sodium_pad (execute_data=0xb781a0a0,
#1 0x083f7d04 in ZEND_DO_ICALL_SPEC_RETVAL_UNUSED_HANDLER ()
#2 execute_ex (ex=0x37400010)
#3 0x084002b4 in zend_execute (op_array=op_array@entry=0xb787c000,
#4 0x08363690 in zend_execute_scripts (type=type@entry=0x8,
#5 0x0830344e in php_execute_script (
#6 0x084026db in do_cli (argc=argc@entry=0x2,
#7 0x08071637 in main (argc=0x2, argv=0x8af8000)
#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
Add a Pull Request
Any update?Security Issue?
On a quick glance, the check `blocksize > SIZE_MAX` looks
fishy. Frank, could you please have a look at this issue?
What system is that on? Is it a 32 bit system?
Yes,Ubuntu 14.04 x86
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?
However, I was using the latest version. When I compiled the sodium, this poc would cause a crash.Maybe it has been fixed?
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.
But the root cause should rather be fixed.
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.
I'd consider this a security issue. Which is trivial to trigger:
$a = str_repeat('x', 2147483647);
$b = $a . $a;
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.
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
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
Yes, @spam2.rhsoft.net,In the past, this should be classified as a security issue