php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #73282 Endless loop in SHA3-224
Submitted: 2016-10-10 11:07 UTC Modified: 2016-11-01 16:41 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: rainer dot jung at kippdata dot de Assigned: pollita (profile)
Status: Closed Package: hash related
PHP Version: 7.1.0RC3 OS: Solaris 10 Sparc
Private report: No CVE-ID: None
 [2016-10-10 11:07 UTC] rainer dot jung at kippdata dot de
Description:
------------
Tests sha3 and hash_copy_001 do not terminate. They run in an endless loop consuming CPU. Stacks:

#0  0xfed08a00 in PHP_SHA3_Final (digest=<optimized out>, digest_size=28, block_size=144, ctx=0xfe45f700)
    at /some/path/ext/hash/hash_sha3.c:179
No locals.
#1  PHP_SHA3224Final (digest=0xfe456250 "", ctx=0xfe45f700) at /some/path/ext/hash/hash_sha3.c:224
No locals.
#2  0xfecf2d50 in php_hash_do_hash (isfilename=<optimized out>, raw_output_default=<optimized out>,
    return_value=<error reading variable: Unhandled dwarf expression opcode 0xfa>, return_value=<error reading variable: Unhandled dwarf expression opcode 0xfa>,
    execute_data=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at /some/path/ext/hash/hash.c:160
        algo = 0xfe455530 "sha3-224"
        data = 0x3cff8 ""
        algo_len = 8
        data_len = 0
        raw_output = 0 '\000'
        ops = 0xff0744a4
        context = 0xfe45f700
        stream = <optimized out>
#3  0xfeea086c in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER (execute_data=0xfe414020)
    at /some/path/Zend/zend_vm_execute.h:675
        opline = 0xfe475380
        call = 0xfe414110
        fbc = <optimized out>
        ret = <optimized out>
#4  0xfee8a240 in execute_ex (ex=<optimized out>) at /some/path/Zend/zend_vm_execute.h:432
        ret = <optimized out>
        execute_data = 0xfe414020
#5  0xfeefaadc in zend_execute (op_array=0xfe461080, return_value=<optimized out>)
    at /some/path/Zend/zend_vm_execute.h:474
No locals.

with

(gdb) print *ctx
$1 = {state = "\006", '\000' <repeats 142 times>, "\200", '\000' <repeats 55 times>, pos = 1}
(gdb) print &(ctx->state[block_size-1])
$2 = (unsigned char *) 0xfe45f78f "\200"


and


#0  0xfed08a00 in PHP_SHA3_Final (digest=<optimized out>, digest_size=28, block_size=144, ctx=0xfe45f1c0)
    at /some/path/ext/hash/hash_sha3.c:179
No locals.
#1  PHP_SHA3224Final (digest=0xfe456250 "▒W=\016?l>-\027L\223Z5▒▒1\003/\004▒▒4\231▒<▒h", ctx=0xfe45f1c0)
    at /some/path/ext/hash/hash_sha3.c:224
No locals.
#2  0xfecf2958 in zif_hash_final (execute_data=0xfe414260, return_value=0xfe414120) at /some/path/ext/hash/hash.c:510
        zhash = 0xfe414290
        hash = 0xfe46a060
        raw_output = 0 '\000'
        digest_len = 28
#3  0xfeea086c in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER (execute_data=0xfe414020)
    at /some/path/Zend/zend_vm_execute.h:675
        opline = 0xfe477284
        call = 0xfe414260
        fbc = <optimized out>
        ret = <optimized out>

with

(gdb) print *ctx
$1 = {state = "I can't remember anything\006", '\000' <repeats 117 times>, "\200", '\000' <repeats 55 times>, pos = 26}
(gdb) print &(ctx->state[block_size-1])
$2 = (unsigned char *) 0xfe45f24f "\200"



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-10-12 03:40 UTC] pollita@php.net
-Status: Open +Status: Verified -Assigned To: +Assigned To: pollita
 [2016-10-12 03:48 UTC] pollita@php.net
-Status: Verified +Status: Closed
 [2016-10-12 03:48 UTC] pollita@php.net
Nice catch.  The problem was specific to Big Endian systems so wasn't caught by anyone running this test on x86/x86_64.  I reproduced by flipping the compat flag locally, then found the dumb mistake someone* made in the initial implementation.

Fix at https://github.com/php/php-src/commit/b041bebb88db17a5fbd72c40047aaca944f9e392

* Spoiler alert, I'm the dumb someone.
 [2016-11-01 05:34 UTC] rainer dot jung at kippdata dot de
Thanks for the fix. The bug was closed 20 days ago, but the fix didn't yet land in PHP 7.1 Any plan to merge to 7.1? The problematic code is not in 7.0 or any 5.x, but it is in 7.1 and was still in RC5 (and the problem again occured in RC 5).
 [2016-11-01 16:32 UTC] pollita@php.net
Ooops.  Does this algo exist in 7.1 as well? Awkward... I had it in my head as a new 7.2-only algo.  Yeah, I'll merge it back, sorry.
 [2016-11-01 16:41 UTC] pollita@php.net
Now on PHP-7.1 branch
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Fri Sep 17 08:03:36 2021 UTC