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.
You kept talking about some configuration change that makes things "overblown", without making it clear you meant "turn off PHP". So yes that's misinformation.
It's not overblown if the only non-patch fix is "turn off PHP".
And that's assuming you actually meant "turn off PHP" the entire time? Your earlier phrasing suggests you have something that leaves PHP running in mind, but if that's entirely hypothetical then again we're back to misinformation. (And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix.)
My first statement was "Not having made the claim", to indicate that I do not necessarily think that. My second was "took down my website too" to indicate, based on what understanding I did and plan to act on.
> And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix
The config could be, run a simulation on the input data to decide whether it would allow for RCE and then decide whether to run PHP or not. I sure hope nobody is actually doing that, but it is sure possible.
> And that's assuming you actually meant "turn off PHP" the entire time?
I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.
> The config could be, run a simulation on the input data to decide whether it would allow for RCE and then decide whether to run PHP or not. I sure hope nobody is actually doing that, but it is sure possible.
That is not a config. That's a whole new program.
> My first statement was "Not having made the claim", to indicate that I do not necessarily think that. My second was "took down my website too" to indicate, based on what understanding I did and plan to act on.
But with everything else you still made it sound like you were supporting it.
> I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.
It satisfies it, but in a way that doesn't make the exploit overblown.
It's obvious that you can avoid a PHP exploit by turning off PHP. That's not nearly enough to make the worries overblown.
"It could be even worse" is the only conclusion we can draw from it being in php and not the web server. And that conclusion is basically meaningless.
That's the distinction between being able to do something or not if you do not have control over the webserver, as is likely the case for a lot or PHP websites, so I wouldn't say it's meaningless.
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.
None. Like I wrote "I don't know, I hope my provider patched it properly."
Then why did you say
> you can prevent PHP being executed on malicious data by configuring the webserver.
Configure your webserver to not execute PHP code.
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?
> I don't know how
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.
> You are spreading misinformation then.
?
> 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.
So basically what you're saying is you aren't vulnerable if you turn off your website.
The server configuration to mitigate this is to comment out the whole configuration so there's no server.
You kept talking about some configuration change that makes things "overblown", without making it clear you meant "turn off PHP". So yes that's misinformation.
It's not overblown if the only non-patch fix is "turn off PHP".
And that's assuming you actually meant "turn off PHP" the entire time? Your earlier phrasing suggests you have something that leaves PHP running in mind, but if that's entirely hypothetical then again we're back to misinformation. (And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix.)
Edit: stray "not"
My first statement was "Not having made the claim", to indicate that I do not necessarily think that. My second was "took down my website too" to indicate, based on what understanding I did and plan to act on.
> And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix
The config could be, run a simulation on the input data to decide whether it would allow for RCE and then decide whether to run PHP or not. I sure hope nobody is actually doing that, but it is sure possible.
> And that's assuming you actually meant "turn off PHP" the entire time?
I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.
> The config could be, run a simulation on the input data to decide whether it would allow for RCE and then decide whether to run PHP or not. I sure hope nobody is actually doing that, but it is sure possible.
That is not a config. That's a whole new program.
> My first statement was "Not having made the claim", to indicate that I do not necessarily think that. My second was "took down my website too" to indicate, based on what understanding I did and plan to act on.
But with everything else you still made it sound like you were supporting it.
> I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.
It satisfies it, but in a way that doesn't make the exploit overblown.
It's obvious that you can avoid a PHP exploit by turning off PHP. That's not nearly enough to make the worries overblown.
"It could be even worse" is the only conclusion we can draw from it being in php and not the web server. And that conclusion is basically meaningless.
> And that conclusion is basically meaningless.
That's the distinction between being able to do something or not if you do not have control over the webserver, as is likely the case for a lot or PHP websites, so I wouldn't say it's meaningless.