Bug #81513 [PATCH]: PHP-FPM heap overflow under strange configuration

Edit report at https://bugs.php.net/bug.php?id=81513&edit=1 ID: 81513 Patch added by: bukka@php.net Reported by: c dot fol at ambionics dot io Summary: PHP-FPM heap overflow under strange configuration Status: Assigned Type: Bug Package: FPM related PHP Version: 8.1.0RC3 Assigned To: bukka Block user comment: N Private report: N New Comment: The following pull request has been associated: Patch Name: Fix bug #81513 (Future possibility for heap overflow in FPM zlog) On GitHub: https://github.com/php/php-src/pull/7632 Patch: https://github.com/php/php-src/pull/7632.patch Previous Comments: ------------------------------------------------------------------------ [2021-11-07 21:01:57] bukka@php.net Yes it's a code bug and should be fixed as a normal bug. ------------------------------------------------------------------------ [2021-11-01 11:16:36] c dot fol at ambionics dot io Hello bukka, You're right (I believe) ! There's maybe an edge case that we didn't think about... but I can't find it. However, although it is safe, it is still "wrong": (re)allocation should be in function of the full length (cursor position + additional size). Just because we can't find a path doesn't mean it does not exist or won't in the future... Just my 2 cents. Charles ------------------------------------------------------------------------ [2021-10-31 21:29:58] bukka@php.net So I looked a bit more into this one and did a little bit of debugging and not sure if this can even happen. The part that you might have missed is this: https://github.com/php/php-src/blob/8a79668dbe2044bbcae8720114ffea0edc160436/sapi/fpm/fpm/zlog.c#L474-L482 Just to note zlog_stream_buf_append is the only function that can add longer string to zlog_stream_buf_copy_cstr (others are just short prefixes) and it seems to already handle wrapping before the call so it doesn't seem possible to get to the path where MAX(size * 2, needed) would use needed. It should always go through the size * 2 path which should mean that there will be always enough space for the copied string and it should never overflow though. At least I wasn't able to find any case where it would overflow for me. But it's a bit late so I might have missed something. Please correct me if there's a path that I missed. If you could also give me some recreateable code (just basically few strings that would overflow if processed by zlog buffering - doesn't need to be a full exploit though...), that would be great. ------------------------------------------------------------------------ [2021-10-18 19:35:29] bukka@php.net The above comment about PHP 7.3 should be in different bug so pls ignore ------------------------------------------------------------------------ [2021-10-18 14:32:14] bukka@php.net Just to clarify, the PHP 7.3 support ends in something over one month on 6th December so it's most likely just one extra final security release which wouldn't most likely contain any fixes if there are any problems with this. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=81513 -- Edit this bug report at https://bugs.php.net/bug.php?id=81513&edit=1