Extremely wrong. I'm not sure how "RCE on every PHP server, from anywhere on the internet, no other requirements" could possibly be underblown by anyone. Exploiting the PHP request parser bypasses basically all security checks and it doesn't matter how secure your code is because the exploitable component runs before your code and can't be disabled.
I am very curious to hear why you thought it was overblown.
There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day.
"There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day."
Part of the confusion is that the initial PR for the release made it sound like there was a ready-to-go exploit that was just push button, get shell on any PHP server in the world. That turned out not to be the case, as evidenced by the fact that the number was 19 hours and not 19 minutes.
But the fact that it was 19 hours and not "never" also does provide a data point that everything that was vulnerable really was vulnerable, it just may not have been quite as vulnerable as it was initially presented. Still plenty vulnerable, of course.
My point here being that the initial 24 hours were very confusing and I think it's worth remembering that and giving people grace for it. Even now, I've heard rumors of an exploit that does work on all boxes without making changes for a specific target but I'm not actually sure whether that exists or not. (Any further info welcome.)
This exploit depends on the deployment. With PHP-FPM, an OOM during request startup terminates the child, so the corrupted state wouldn’t survive for subsequent requests to exploit. The challenge used PHP’s built-in server, where the worker was reused.
Doesn't mean that there isn't another exploit chain that can be used though. Challenge also had 4 workers total, so pining one worker wasn't that hard.
In online communities right now there’s a lot of demand for evidence of LLM capabilities being overblown. It’s unfortunate that even if the steal my bitcoin creator apologizes for spreading misinformation due to incompetence, the truth won’t be spread as widely.
Shutting down half the internet was the right move. If it took someone 19 hours to exploit a site, you'd better have shut it down before 19 hours and not after.
I don't see what was confusing about the initial 24 hours. GP was correct, the description of the bug made it clear it was a very high risk.
Also, unless I am reading this wrong, it does not seem like what actually got the bitcoin was a 2shell-like exploit? Seems like memory corruption leading to printing out the flag through just http requests? How would you use this outside of a CTF context?
2shell is catchy shorthand for "do anything". log4shell (originator of the name?) didn't directly give you a shell either, it ran some Java code. You could have a shell if you wanted to.
I think it goes back to the huge amount of anti-AI sentiment that's out there today. Any AI accomplishment gets undersold by haters, i.e. people maintaining that the Navier-Stokes solution was stolen, people saying that Lean proofs can't be relied on, exploits like PHP2Shell are esoteric and not usable in the real-world, etc. Those are just comments I recall reading off the top of my head but I could find sources if anyone wants. I think it's just a way for people to cope and fool themselves into thinking that this whole AI thing isn't a big deal and will just blow over.
> I'm not sure how "RCE on every PHP server, from anywhere on the internet, no other requirements" could possibly be underblown by anyone
It could be overblown if it's not true. The amount of time it took for anyone to claim the Bitcoin from the supposedly-vulnerable PHP site convinced a lot of people that the vulnerability was not as bad as claimed.
Why would someone send their exploit chain to a random for a mediocre 'bug bounty'. The bounty was later claimed by people who just did It for fun after work for fun with a LLM of their choice quickly.
There were prominent people saying stuff like "this bug is so bad, every PHP server is vulnerable to any script kiddie with an LLM; simultaneously, my exploit is so valuable and secret that I don't want to tell you what it is; also although I could totally steal this bitcoin, I choose not to, but I totally could if I wanted to".
Which is pretty indistinguishable from people just lying about how bad it is? How are you meant to tell the difference? How can it both be true that the server is vulnerable to any script kiddie with an LLM but your exploit is too valuable to share?
And the fact that the server turned out to be not exploitable just proves that the people claiming to be able to exploit it in fact were lying.
wasn't it setup in an unexploitable configuration (not actually serving a php page IIRC?) for most of the time, and then got popped within like 2 hours once fixed?
Under normal configurations the server is highly exploitable.
It's a horrible vuln and I don't understand what's with all the flat infosec society coming out of the woodwork.
The challenge server had vibe coded infra that made it hard or impossible to hack, but it was a configuration that can't be used in production and no one uses ( it was deployed as a PHP static content server instead of a dynamic site generator )
>I don't understand what's with all the flat infosec society coming out of the woodwork.
Ha, while most of these are probably humans that are just being driven mad by AI, I wonder how long before we get AI driven botnets that try to under play any security vulns to give them more time to take over and collect assets for themselves?
Where is all the evidence of exploits if most of the webs PHP servers were vulnerable?
This is a seperate chained exploit itself, seemingly executed by a nation stae. There are thousands of exploits infiltrating web servers around the world daily, and they arent php2shell.
You only care about this because it falls into a weird viral narrative about "AI saftey".
> I am very curious to hear why you thought it was overblown.
Not having made the claim (took down my website too), but because PHP is not connected directly to the network. While you cannot prevent PHP from being overtaken from inside the PHP program, you can prevent PHP being executed on malicious data by configuring the webserver. It's overblown in the sense that it would be even more serious if the same happened in the webserver itself.
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.
Its overblown in the sense that 70% of the internet was not in fact vulnerable, as widely reported. And not everyone is a hackor because they have access to llms. Go look at normie coverage from people like Linus tech tips and you'll see them saying how millions of servers were under attack by script kiddies with llms, amd how llms are so dangerous.
The whole thing was basically a psyop, whether intential or not idk but Califs research was funded in part by OpenAI so there's that.
I agree. There's nuance to it. I believe the CVE was overblown, and I also believe that it is a severe vulnerability that should be addressed ASAP. 2 things can be true at once.
It was OpenAI's marketing that hyped up the vulnerability to the point that guys on my hockey team saw it in the news and were asking about it. There doesn't need to be mainstream articles about it, these kinds of vulnerabilities happen every year. Just patch and move on.
The CVE was not overblown. It's correctly marked as a 9.2.
Random bloggers jumped on it and said dumb blogger things. That is all.
This is one of the worst vulns ever and the security response from the people who actually secure things for a living was entirely warranted regardless of whether some blogger thought it was the AI apocalypse or not.
Respect, hats off to reevaluate when presented with the info. Will fully admit, I myself lacked the ability to assess the true severity, mainly cause I try to stay away from PHP since my first encounter in sixth grade, so was going a bit back-and-forth due to what I was reading.
Mainly saw the severity in the economic impact of having to quickly patch so much, but taking offline being the right choice given the risk, along with of course all the decades old, never patches, blogs being botnet targets someday in the future, akin to Wordpress being commonly used for Ransomware hosting for similar reasons. And of course hopefully learning something from the timeline and leak for future disclosures. Feel things need to generally change from the status quo, barely has changed since the 2015 Google/MSFT squabble...
Yes, you were. These exploits are happening in processes like php-fpm before it actually executes any code for the web application, so its not like you need to find endpoint where a specific class is being invoked or anything like that.
> When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
I find statements like yours to not be about objective truth, but rather a narcissistic view of world where if it was hard for you, it must not be possible. It is more of a comparison of yourself vs the world.
Extremely wrong. I'm not sure how "RCE on every PHP server, from anywhere on the internet, no other requirements" could possibly be underblown by anyone. Exploiting the PHP request parser bypasses basically all security checks and it doesn't matter how secure your code is because the exploitable component runs before your code and can't be disabled.
I am very curious to hear why you thought it was overblown.
There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day.
"There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day."
19 hours: https://stealmybitcoin.com/
Part of the confusion is that the initial PR for the release made it sound like there was a ready-to-go exploit that was just push button, get shell on any PHP server in the world. That turned out not to be the case, as evidenced by the fact that the number was 19 hours and not 19 minutes.
But the fact that it was 19 hours and not "never" also does provide a data point that everything that was vulnerable really was vulnerable, it just may not have been quite as vulnerable as it was initially presented. Still plenty vulnerable, of course.
My point here being that the initial 24 hours were very confusing and I think it's worth remembering that and giving people grace for it. Even now, I've heard rumors of an exploit that does work on all boxes without making changes for a specific target but I'm not actually sure whether that exists or not. (Any further info welcome.)
It's not 19hours. The server was originally configured with no running php. Once they added a php file, the server got pwned in 2 hours.
Interesting. I did not know that. (Obviously.)
This exploit depends on the deployment. With PHP-FPM, an OOM during request startup terminates the child, so the corrupted state wouldn’t survive for subsequent requests to exploit. The challenge used PHP’s built-in server, where the worker was reused.
Doesn't mean that there isn't another exploit chain that can be used though. Challenge also had 4 workers total, so pining one worker wasn't that hard.
In online communities right now there’s a lot of demand for evidence of LLM capabilities being overblown. It’s unfortunate that even if the steal my bitcoin creator apologizes for spreading misinformation due to incompetence, the truth won’t be spread as widely.
Shutting down half the internet was the right move. If it took someone 19 hours to exploit a site, you'd better have shut it down before 19 hours and not after.
I don't see what was confusing about the initial 24 hours. GP was correct, the description of the bug made it clear it was a very high risk.
Also, unless I am reading this wrong, it does not seem like what actually got the bitcoin was a 2shell-like exploit? Seems like memory corruption leading to printing out the flag through just http requests? How would you use this outside of a CTF context?
https://github.com/KillaBoi/StealMyBitcoin-PoC
2shell is catchy shorthand for "do anything". log4shell (originator of the name?) didn't directly give you a shell either, it ran some Java code. You could have a shell if you wanted to.
I think it goes back to the huge amount of anti-AI sentiment that's out there today. Any AI accomplishment gets undersold by haters, i.e. people maintaining that the Navier-Stokes solution was stolen, people saying that Lean proofs can't be relied on, exploits like PHP2Shell are esoteric and not usable in the real-world, etc. Those are just comments I recall reading off the top of my head but I could find sources if anyone wants. I think it's just a way for people to cope and fool themselves into thinking that this whole AI thing isn't a big deal and will just blow over.
> I'm not sure how "RCE on every PHP server, from anywhere on the internet, no other requirements" could possibly be underblown by anyone
It could be overblown if it's not true. The amount of time it took for anyone to claim the Bitcoin from the supposedly-vulnerable PHP site convinced a lot of people that the vulnerability was not as bad as claimed.
Why would someone send their exploit chain to a random for a mediocre 'bug bounty'. The bounty was later claimed by people who just did It for fun after work for fun with a LLM of their choice quickly.
There were prominent people saying stuff like "this bug is so bad, every PHP server is vulnerable to any script kiddie with an LLM; simultaneously, my exploit is so valuable and secret that I don't want to tell you what it is; also although I could totally steal this bitcoin, I choose not to, but I totally could if I wanted to".
Which is pretty indistinguishable from people just lying about how bad it is? How are you meant to tell the difference? How can it both be true that the server is vulnerable to any script kiddie with an LLM but your exploit is too valuable to share?
And the fact that the server turned out to be not exploitable just proves that the people claiming to be able to exploit it in fact were lying.
wasn't it setup in an unexploitable configuration (not actually serving a php page IIRC?) for most of the time, and then got popped within like 2 hours once fixed?
The point is, under normal configurations when you're serving the PHP server correctly with table-stakes best practices the server is not exploitable
This was not a scary vuln at all.
Under normal configurations the server is highly exploitable.
It's a horrible vuln and I don't understand what's with all the flat infosec society coming out of the woodwork.
The challenge server had vibe coded infra that made it hard or impossible to hack, but it was a configuration that can't be used in production and no one uses ( it was deployed as a PHP static content server instead of a dynamic site generator )
>I don't understand what's with all the flat infosec society coming out of the woodwork.
Ha, while most of these are probably humans that are just being driven mad by AI, I wonder how long before we get AI driven botnets that try to under play any security vulns to give them more time to take over and collect assets for themselves?
Are you sure this isn’t already happening?
Normal configuration of a PHP server is to not run any PHP code and serve a static html file?
Where is all the evidence of exploits if most of the webs PHP servers were vulnerable?
This is a seperate chained exploit itself, seemingly executed by a nation stae. There are thousands of exploits infiltrating web servers around the world daily, and they arent php2shell.
You only care about this because it falls into a weird viral narrative about "AI saftey".
There's nothing separate about this.
Chained just means they used php2shell to run a local privilege escalation.
Was the exploit not dependent on a kernel exploit that was disclosed and patched in may, or am I just hallucinating?
Depends which part: php2shell does what it says on the tin: lets you run arbitrary commands as www-data.
If you want more than that you need to chain an LPE. Which are plenty these days sadly.
Which best practices did you use to prevent exploitability?
And would you stake your bitcoin on it?
I had a similar take, but I was wrong.
How were you wrong? Out of 15k targets scanned they arrived at 25 servers total.
> I am very curious to hear why you thought it was overblown.
Not having made the claim (took down my website too), but because PHP is not connected directly to the network. While you cannot prevent PHP from being overtaken from inside the PHP program, you can prevent PHP being executed on malicious data by configuring the webserver. It's overblown in the sense that it would be even more serious if the same happened in the webserver itself.
Can you? Initial suggestions to block multipart content-types were a red herring.
In theory yes. In practice, I don't know, I hope my provider patched it properly.
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.
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.
Reminds me a recent article that went viral on HN, claiming: "There isn't an easy exploit for this PHP vulnerability"..
https://news.ycombinator.com/item?id=50188948
Its overblown in the sense that 70% of the internet was not in fact vulnerable, as widely reported. And not everyone is a hackor because they have access to llms. Go look at normie coverage from people like Linus tech tips and you'll see them saying how millions of servers were under attack by script kiddies with llms, amd how llms are so dangerous.
The whole thing was basically a psyop, whether intential or not idk but Califs research was funded in part by OpenAI so there's that.
I agree. There's nuance to it. I believe the CVE was overblown, and I also believe that it is a severe vulnerability that should be addressed ASAP. 2 things can be true at once.
It was OpenAI's marketing that hyped up the vulnerability to the point that guys on my hockey team saw it in the news and were asking about it. There doesn't need to be mainstream articles about it, these kinds of vulnerabilities happen every year. Just patch and move on.
The CVE was not overblown. It's correctly marked as a 9.2.
Random bloggers jumped on it and said dumb blogger things. That is all.
This is one of the worst vulns ever and the security response from the people who actually secure things for a living was entirely warranted regardless of whether some blogger thought it was the AI apocalypse or not.
This was a vulnerability worse than Heartbleed. Did they hear about Heartbleed?
Respect, hats off to reevaluate when presented with the info. Will fully admit, I myself lacked the ability to assess the true severity, mainly cause I try to stay away from PHP since my first encounter in sixth grade, so was going a bit back-and-forth due to what I was reading.
Mainly saw the severity in the economic impact of having to quickly patch so much, but taking offline being the right choice given the risk, along with of course all the decades old, never patches, blogs being botnet targets someday in the future, akin to Wordpress being commonly used for Ransomware hosting for similar reasons. And of course hopefully learning something from the timeline and leak for future disclosures. Feel things need to generally change from the status quo, barely has changed since the 2015 Google/MSFT squabble...
Yes, you were. These exploits are happening in processes like php-fpm before it actually executes any code for the web application, so its not like you need to find endpoint where a specific class is being invoked or anything like that.
I commend you to having corrected your thoughts this publicly fwiw.
We need more of this.
Perhaps you violated Clarke's First Law
> When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
I find statements like yours to not be about objective truth, but rather a narcissistic view of world where if it was hard for you, it must not be possible. It is more of a comparison of yourself vs the world.
See also https://news.ycombinator.com/item?id=50224916 https://news.ycombinator.com/item?id=50225703