Hacker News

points by cowlevel 15 hours ago | 0 comments

What specific configuration would you recommend to block the vulnerability without actually patching it?

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.

[–] 1718627440 15 hours ago

None. Like I wrote "I don't know, I hope my provider patched it properly."

[–] cowlevel 15 hours ago

Then why did you say

> you can prevent PHP being executed on malicious data by configuring the webserver.

[–] jstanley 14 hours ago

Configure your webserver to not execute PHP code.

[–] 1718627440 14 hours ago

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.

[–] cowlevel 14 hours ago

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?

[–] 1718627440 13 hours ago

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?

[–] kxrm 13 hours ago

> 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.

[–] 1718627440 13 hours ago

> 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.

[–] cowlevel 6 hours ago

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.

[–] Dylan16807 8 hours ago

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"

[–] 1718627440 8 hours ago

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.