Re: [PHP-DEV] Categorising engine bugs caused by nonsensical/malicious callback handlers as Undefined Behaviour and to not fix them

Hi Gina

On 08.09.26 14:06, Gina P. Banyard wrote:
> Over the last few years, more and more issues have been opened where a user defined error handler (or other callbacks) causes a Use After Free (UAF) when said error handler modifiers the variable/property that triggered the warning/deprecation/whatever.
> These issues are usually found via fuzzing, or more recently LLMs.
*snip*
> One potential idea that has been floating around is to delay error handlers. [1]
> However, these issue are likely to also happen from other callbacks such as a class autoloader, a tick handler, an output handler, etc. as nothing prevents them from messing around with $GLOBALS or binding a variable to its scope.
>
> While having C memory bugs is *far* from ideal, the fact that a majority of them will disappear with PHP 9 when deprecation are removed and warnings are promoted to Error makes this whackamole bug chase a waste of time. Especially as these issues have been present for *decades* and nobody except fuzzers and LLMs have run into these issues.

I very much share this sentiment. Yes, ideally there are no ways to 
trigger memory violations in PHP. However, while such bugs can be 
catastrophic for other languages like JavaScript where it's expected to 
run untrusted code on your computer, the same doesn't apply to PHP. 
These bugs are effectively impossible to trigger by accident and thus 
have no real-world consequence, and yet take up a very large chunk of 
our time (both in terms of issues and reviews.

> As such I'd like to hear the opinions of Internals on if we can come to a consensus (ideally without an RFC...) that registering callbacks that mess around with state in non-intended ways is Undefined Behaviour (UB).

I'd still very much be in favor of fixing these issues, mainly because 
they are a big time sink for the security team as well, due to 
false-positive reports. Arnaud and I were planning on proposing an RFC 
that mitigates at least a large portion of them, before we got occupied 
with other things.

I absolutely do not think each case should be considered individually, 
because we already tried this and the issues never stop coming.

> While UB is far from desirable, it is not unprecedented in PHP.
> Prior to PHP 8, the behaviour of internal functions when given values of invalid types was considered UB, sometimes it returned false, sometimes, null, sometimes it threw an Error.
> This was fixed by throwing TypeErrors consistently.

The above might not all be problematic. E.g. the number of handlers that 
produce output are fairly limited. The reports we do get that use them 
rely on warnings printed to the output buffer, but if we can delay 
warnings then this goes away as well. Similarly, not that many handlers 
trigger autoloading. So this might be easier to control. But I did not 
verify my claims here. But if cases remain that aren't possible to fix, 
I wouldn't mind officially disallowing them.

Ilija