← Back to context

Comment by cowlevel

6 hours ago

Then why did you say

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

6 comments

cowlevel

Reply
1718627440  5 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  5 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  4 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  4 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  4 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.