Social media and "cybersecurity experts" had a big role in this. Stuff like "EU SAYS THIS IS A URGENT VULNERABILITY" (they cite "the experts" posts on social media), and even the Prime Minister of Japan. None of these organizations or bodies had any details other than what was on the advisories and social media. (e.g "CVSS 10, that's bad!!")
To me, it seems more more akin to broadpwn, technically severe, wide scope (millions of iphones), yet no one-size-fits-all-PWN-button.
Even in the age of AI, I don't think this is going to be weaponized down the line like how Eternalblue was... but I'm not the social media cybersec guy with 15000 followers, so don't take my words at face value ;)
Anime girl level cataclysmic security events definitely don't worry me as much as laughing man (笑い男) cataclysmic events; only then it's when I really start to panic.
I've seen many posts like this. None of them stood the test of time. Ease is irrelevant because you only need expertise once and then everyone can reuse the result.
It's also not easy to pop an iPhone, but reliable, weaponized exploits are available in trade and governments use them in a plug-and-play way.
The specific controversy here is about the disclosure timeline. Some people allege that the disclosure and patch release of this vulnerability were mishandled; others dispute this. The dispute turns crucially on how available exploits were during the embargo period. Nobody is arguing that the vulnerability doesn't need to be patched at all. (The PHP core team didn't initially treat it with much urgency, but they've acknowledged that this was a mistake.)
Time is the whole point though. Everyone was terrified and shutting their websites down because they believed the exploit would be running wild on the internet in between it hitting git and them being able to update the server.
If it takes a week to come up with a working exploit code, the critical services have time to update.
Time is part of the point, but it is not the whole point. The whole point involves the fact that this impacts two decades worth of PHP versions. Even if it took months to exploit, there is going to be a long, long tail of breaches against ill-maintained legacy sites.
Huh, I thought we were talking about this because it's a massive security breach offering approximately unconditional RCE against half of the servers on the open web.
You can never rule out the possibility that someone interested in attacking you has a non-public exploit, but it's dramatically less likely if there aren't already working exploits circulating all over the internet.
That "if" is load bearing and increasingly flat-out false.
Crowdstrike's average "breakout times", the time gap between a first successful infiltration and maximal exploitation, has gone from days or hours prior to 2024 to minutes or seconds now.
I ran 2 PoCs from GitHub today: one indeed expected Local File Inclusion (LFI) to already be present (so it's just LFI with extra steps), and the other one didn't work at all out of the box without some modifications (although I used the same Docker images and all). The second PoC did trigger a real stale write bug in the end, but it didn't demonstrate actual RCE; it just triggered a stale write. And then I wondered, is this the first time ever that the PHP runtime has had a memory corruption bug? I doubt it (I remember a few years ago we had random crashes in production under high load due to an opcache bug). And if it's not the first memory corruption bug in the PHP runtime, why is it being proclaimed the worst vulnerability in years?
There is an argument to be made that taking down such a sizable chunk of the Internet automatically qualifies it as a pretty severe vulnerability, even if no actual exploits were involved in causing it.
More seriously, though, I read it as bad because of the potential. All versions of PHP going back a full two decades were affected, all users of PHP are affected regardless of which features they use, and it’s still unclear if there’s an effective mitigation. So the blast radius if anyone does/dis have a working exploit would have been enormous.
The difference is that PHP has a long history of vulnerabilities while platforms like Java don't. And as bad as Log4Shell was, it wasn't a problem with the core runtime. It wasn't even a problem with the most popular logging framework at the time.
On the other hand, my local qwen model (3.8-flash-next) was trying to convince me that the eMudhra CA thing is no big deal since you need to be "positioned correctly" (eg: any wifi network) to be able to MITM, and most of the IOT devices would have patched stuff by now.
What kind of pisses me off was that there were kind of two sides of the continuum.
You've got the detailed technical writeup on one end in the patches themselves, and on the other end you've essentially got the AI and security companies both together (php2shell) and independently with their highly polished microsites and blog posts with attractive infographics and stylized pitch deck looking images.
Every publication on the other side of the detailed technical writeup in the patches themselves wanted to make it into a huge fucking marketing stunt first and foremost, providing absolutely zero added practical benefit or value.
The certificates incident was mitigated by the fact it was revoked within hours so by the time people found out, it was resolved.
Yes there is a long tail of Internet of Shit devices that have a fixed non updated cert store, but these devices are being absolutely ripped to shreds by AI from all angles already.
The biggest problem is that for a good 12 hours nobody knew what was going on. All we knew was there is a critical vulnerability affecting all of us that allows RCE somehow and we have to have vulnerable servers open for potentially even longer.
Everyone who knew was being hush hush, only chiming in to say "nah, those workarounds don't work, you're fucked".
So when people started spreading rumors of PoC or when the Cloud flare CTO posted that they were actively seeing exploit traffic - what are we supposed to do?
We aren't sitting there trying to PoC with Claude - we're subscribing to a bunch of news feeds and twitter accounts while we try to prepare for the patch and close down what we can. We're calling executives saying "hey, how much money do we lose by being offline for 6 hours?"
So even if this isn't as easily exploitable as first believed, no one could have known that, because those with the ability to calm us down were seemingly choosing to stoke the fires.
This is (IMO) a failure of the potentially outdated disclosure system that's supposed to protect us. And at the very least a trial run of how the world may react next time, if it really is that bad.
Very well said. Even for non-sensitive stuff that I was told was "super vulnerable", I didn't know if this was a full, actual RCE - some places said yes, others no. Did I need to take down everything running PHP? Just the apps dealing with data I didn't want leaked? Etc.
The rather long delay in getting official Docker images didn't help; we were told "patch now!!1!!" but that apparently meant building from source.
Yeah, I suggested to take down the app someone between seeing the Gina (core) comment (saying php.ini etc changes won't do anything) and after seeing the Cloudflare CTO tweet.
Great reply, this hits the nail in the head and is pretty much exactly how I spent my day. Just reading, waiting and stressing while being essentially in the dark about the whole thing.
I'm assuming the next few days will probably confirm if this was mostly FUD or not.
> When I think about "we're very fucked" CVE10s on the Internet, I think of the following vulnerabilities:
Which is IMHO a really good list. It's also, I think, important to note that every single one of the four items is not at all a memory safety bug. They're all logic, at various levels of an interpretation stack.
I think a lot of folks with their heads down in the security world might have expected the opposite. As is often the case in engineering, the smartest people end up obsessing over solving the less important parts of the problem.
I think Heartbleed is close enough to memory safety to count. It was caused by memory allocator returning uninitialized memory and every memory safe language I know about does not allow this in best-practice code.
(And sure, there are escape hatches - like Python has "recv_into" that could be used to implement heartbleed if you are really inclined to - but this would not be a realistic python program. In python, even with buffer reuse, you'd be using memoryview or similar that can't have a heartbleed problem)
Serverside memory corruption is annoying to get working. As a dominant metagame strategy for attackers, it's much more impactful on the clientside.
(I'm not cosigning the analysis in this blog post. I think "I haven't seen a PoC I could get working" is not the evidence this author seems to think it is.)
Glad to be proven wrong but as far as I can see there are no reports of it currently being exploited in the wild at the scale you are implying. It genuinely takes a lot of time to weaponize even with the assistance of frontier LLM models and it is way more difficult when you don't control the server.
I largely agree with the author and it is a common annoyance in cyber security discussions where people make strong claims but have nothing to back it up with.
If anything, claiming that this vulnerability has been known and unpatched for 22 years supports the author's point: clearly it's not that easy to actually use.
Do you have any links to a working PoC that appeared before the details were released? I'm seeing a lot of conflicting info, and I'm not really sure what to think. People saying they were seeing people trying to exploit this hours ahead of the patch release on their servers, yet no one who seemingly actually got pwned by it (were people just misreading their logs?)
To me, it seems more more akin to broadpwn, technically severe, wide scope (millions of iphones), yet no one-size-fits-all-PWN-button.
Even in the age of AI, I don't think this is going to be weaponized down the line like how Eternalblue was... but I'm not the social media cybersec guy with 15000 followers, so don't take my words at face value ;)
> Because:
[…]
> 3. The exploit video had an anime girl in it
Lol, somehow I had missed this. Since I had to dig a bit for it, here it is for everyone’s enjoyment: https://www.youtube.com/watch?v=pfWZrdzvooc (via https://calif.io/php2shell/#php-5-4-0-rce)
It's also not easy to pop an iPhone, but reliable, weaponized exploits are available in trade and governments use them in a plug-and-play way.
If it takes a week to come up with a working exploit code, the critical services have time to update.
If you are a bad actor you probably don't share your PoC around as it means less boxes to hit.
Crowdstrike's average "breakout times", the time gap between a first successful infiltration and maximal exploitation, has gone from days or hours prior to 2024 to minutes or seconds now.
More seriously, though, I read it as bad because of the potential. All versions of PHP going back a full two decades were affected, all users of PHP are affected regardless of which features they use, and it’s still unclear if there’s an effective mitigation. So the blast radius if anyone does/dis have a working exploit would have been enormous.
The difference is that PHP has a long history of vulnerabilities while platforms like Java don't. And as bad as Log4Shell was, it wasn't a problem with the core runtime. It wasn't even a problem with the most popular logging framework at the time.
I wouldn't downplay this.
I can't say if it was most popular overall, but it (Log4Shell) was a nightmare for many F500 companies.
You've got the detailed technical writeup on one end in the patches themselves, and on the other end you've essentially got the AI and security companies both together (php2shell) and independently with their highly polished microsites and blog posts with attractive infographics and stylized pitch deck looking images.
Every publication on the other side of the detailed technical writeup in the patches themselves wanted to make it into a huge fucking marketing stunt first and foremost, providing absolutely zero added practical benefit or value.
https://www.php2shell.com/
https://patchtheplanet.org/
https://www.wiz.io/blog/php2shell-php-rce
https://calif.io/php2shell/
Yes there is a long tail of Internet of Shit devices that have a fixed non updated cert store, but these devices are being absolutely ripped to shreds by AI from all angles already.
I think this section misses the mark.
The biggest problem is that for a good 12 hours nobody knew what was going on. All we knew was there is a critical vulnerability affecting all of us that allows RCE somehow and we have to have vulnerable servers open for potentially even longer.
Everyone who knew was being hush hush, only chiming in to say "nah, those workarounds don't work, you're fucked".
So when people started spreading rumors of PoC or when the Cloud flare CTO posted that they were actively seeing exploit traffic - what are we supposed to do?
We aren't sitting there trying to PoC with Claude - we're subscribing to a bunch of news feeds and twitter accounts while we try to prepare for the patch and close down what we can. We're calling executives saying "hey, how much money do we lose by being offline for 6 hours?"
So even if this isn't as easily exploitable as first believed, no one could have known that, because those with the ability to calm us down were seemingly choosing to stoke the fires.
This is (IMO) a failure of the potentially outdated disclosure system that's supposed to protect us. And at the very least a trial run of how the world may react next time, if it really is that bad.
The rather long delay in getting official Docker images didn't help; we were told "patch now!!1!!" but that apparently meant building from source.
I'm assuming the next few days will probably confirm if this was mostly FUD or not.
> When I think about "we're very fucked" CVE10s on the Internet, I think of the following vulnerabilities:
Which is IMHO a really good list. It's also, I think, important to note that every single one of the four items is not at all a memory safety bug. They're all logic, at various levels of an interpretation stack.
I think a lot of folks with their heads down in the security world might have expected the opposite. As is often the case in engineering, the smartest people end up obsessing over solving the less important parts of the problem.
(And sure, there are escape hatches - like Python has "recv_into" that could be used to implement heartbleed if you are really inclined to - but this would not be a realistic python program. In python, even with buffer reuse, you'd be using memoryview or similar that can't have a heartbleed problem)
(I'm not cosigning the analysis in this blog post. I think "I haven't seen a PoC I could get working" is not the evidence this author seems to think it is.)
I largely agree with the author and it is a common annoyance in cyber security discussions where people make strong claims but have nothing to back it up with.