Hacker News

points by 1718627440 13 hours ago | 0 comments

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 12 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 12 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 12 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 11 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 5 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 7 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 7 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.

[–] Dylan16807 6 hours ago

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

[–] 1718627440 6 hours ago

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