Sec Bug->Bug #81513 [Asn]: PHP-FPM heap overflow under strange configuration

From: Date: Sun, 07 Nov 2021 21:01:57 +0000
Subject: Sec Bug->Bug #81513 [Asn]: PHP-FPM heap overflow under strange configuration
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-237592@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=81513&edit=1 ID: 81513 Updated by: bukka@php.net Reported by: c dot fol at ambionics dot io Summary: PHP-FPM heap overflow under strange configuration Status: Assigned -Type: Security +Type: Bug Package: FPM related PHP Version: 8.1.0RC3 Assigned To: bukka Block user comment: N Private report: Y New Comment: Yes it's a code bug and should be fixed as a normal bug. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2021-10-17 20:03:24] bukka@php.net Ok I see the issue and the report is correct. This is actually my fault as I introduced this logic and completely missed that possibility. I agree that this is a security issue as it can potentially result in buffer overflow which is possible to in some sort of way control especially with decorate_workers_output = no And then just writing specific string to stderr. Although it's quite hard as you say and this setting is often just set for for Docker where the priv escalation might have lower impact as there are other protections as well. Anyway I will think about a test case for this as this might be crashable potentially if I tweak the values correctly. At least I will try. The suggested changes look correct though so the actual fix is pretty small. ------------------------------------------------------------------------ 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

« previous php.bugs (#237592) next »