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
