Open Girgias opened 1 year ago
It looks like this is caused by these lines:
The issue is that classes are only disabled after all classes have been loaded. This includes subclasses, which may have inherited these property infos. Accessing these property infos from the subclass will lead to a use-after-free. Disabling a parent class without also disabling the child class is bogus. I suppose we could recursively disable all subclasses.
Edit: Or we just error saying that the child class must also be disabled. Moreover, I'm not sure if disabling a core class like Exception
can't lead to other issues somewhere.
I'm very much questioning the utility of this "feature" as I would expect loads of issues to arise disabling core classes that we do not at all take into account, and most other objects in extensions are required for them to function properly (imagine disabling the cURL handler)
I've checked ~100 shared www hosts, and disable_classes
wasn't used on any of them, at the same time disable_functions
was used on more than half. In worst case the php source could be patched to explicitly disable some classes, if someone would need to. In most cases php is virtualized or sandboxed anyway. And contrary to ML I don't think that using removed ini directive causes any warnings not to mention fatal errors.
disable_functions
offers a way to rewrite the core functions - disable them and reimplement them in userland before any use.
However, it used to work in a way similar to disable_classes
until a feature request (https://bugs.php.net/bug.php?id=79382, #5473 ) changes it.
Instead of fixing this, we may either deprecate and remove this feature, or change it to the way how disable_functions
now to make it more useful.
@jhdxr As Nikita wrote in the PR, a lot of C code refers to internal classes directly through a pointer, rather than by name and going through the symbol table. This can save a lot of unnecessary lookups when the lookup should always refer to that same class. Furthermore, the reason this feature is currently unreliable is because code internally makes assumptions about the classes and the shape of its instances. If classes can be modified by users it sounds like this issue is going to be exacerbated, rather than mitigated.
disable_functions
offers a way to rewrite the core functions - disable them and reimplement them in userland before any use. However, it used to work in a way similar todisable_classes
until a feature request (https://bugs.php.net/bug.php?id=79382, #5473 ) changes it.Instead of fixing this, we may either deprecate and remove this feature, or change it to the way how
disable_functions
now to make it more useful.
I am planning on removing this outright in 8.4, I just need to work out one small thing.
I am planning on removing this outright in 8.4, I just need to work out one small thing.
I'm OK with remvoing it. Going through the old bug tracker will find it causes more trouble. Security, as the warning message indicates, is not a good reason to keep it as well IMHO, if there is vulnerability in the implementation itself, it should be fixed and user should upgrade PHP. If anyone really wants to disable certain classes, better just disable the whole modules.
However, removing in 8.4 seems too fast. maybe deprecated it in 8.4 and remove it in 8.5?
I am planning on removing this outright in 8.4, I just need to work out one small thing.
I'm OK with remvoing it. Going through the old bug tracker will find it causes more trouble. Security, as the warning message indicates, is not a good reason to keep it as well IMHO, if there is vulnerability in the implementation itself, it should be fixed and user should upgrade PHP. If anyone really wants to disable certain classes, better just disable the whole modules.
However, removing in 8.4 seems too fast. maybe deprecated it in 8.4 and remove it in 8.5?
No, there is utterly no reason for this feature. And this is getting RFCed anyway. Even just having this "deprecated" would mean pottentially fixing issues. And this feature has never worked, has always been pointless, and I doubt has actually ever been used for anything meaningful.
Considering the amount of stuff this declare breaks, this INI setting provides negative value.
Correct me if I'm wrong, but I cannot recall any precedent to remove some documented ini setting and functions without deprecation. Anyway I'm OK with RFC, while I may not vote for an instantly removal.
Description
Found as part of investigating #11884
Disabling a class with typed properties will free a property in
zend_disable_class()
and then again indestroy_zend_class()
Resulted in this output:
I will note, that the engine seems very brittle to disabling classes, as just:
Will not cause any UAF however adding a
var_dump($o);
causes a different UAF:PHP Version
PHP 8.1
Operating System
No response