You could configure your web server to only allow one request per worker, which means the corrupted memory can not get used by the attacker. Not great for performance, obviously.
You can do this. I don't know how, and I don't think it's a feasible use of my time, to find out how. It's obviously computable on a Turing machine, because they were able to patch PHP.
So it was useless advice? You presented it as if anyone not following the advice is incompetent, now you suggest nobody knows how to do it. Is everyone incompetent?
What? I never claimed it was "advice"? I explained how other people could have arrived at the conclusion that there can be worse things than a single language interpreter being vulnerable to a unconditional RCE. Were you answering to the wrong comment?
The configuration change was never a full protection from this vulnerability because the problem is with how PHP processed the request well before the configuration or your PHP code was executed.
> because the problem is with how PHP processed the request well before the configuration or your PHP code was executed.
That's what I wrote? You can't do anything once PHP executed. It could still be worse, because you can still prevent PHP from running, because there is still the webserver before. If it were in the webserver itself, you couldn't do anything, short of stopping the server from running.
> The configuration change was never a full protection from this vulnerability
It is, if the configuration change prevents PHP from running. That's how you could say it is overblown. You are not vulnerable if you don't run PHP.
[–] 1718627440 13 hours ago
[–] cowlevel 12 hours ago
[–] kalleboo 2 hours ago
[–] 1718627440 12 hours ago
[–] cowlevel 12 hours ago
> you can prevent PHP being executed on malicious data by configuring the webserver.
[–] jstanley 12 hours ago
[–] 1718627440 11 hours ago
[–] cowlevel 11 hours ago
[–] 1718627440 10 hours ago
[–] kxrm 10 hours ago
You are spreading misinformation then.
The configuration change was never a full protection from this vulnerability because the problem is with how PHP processed the request well before the configuration or your PHP code was executed.
[–] 1718627440 10 hours ago
?
> because the problem is with how PHP processed the request well before the configuration or your PHP code was executed.
That's what I wrote? You can't do anything once PHP executed. It could still be worse, because you can still prevent PHP from running, because there is still the webserver before. If it were in the webserver itself, you couldn't do anything, short of stopping the server from running.
> The configuration change was never a full protection from this vulnerability
It is, if the configuration change prevents PHP from running. That's how you could say it is overblown. You are not vulnerable if you don't run PHP.