There isn't an easy exploit for this PHP vulnerability

Posted by zkldi 2 hours ago

There isn't an easy exploit for this PHP vulnerability(eliastaylor.com)

155 points | 68 comments

pinevale 1 hour ago|

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.

ameliaquining 1 hour ago||

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

Gigachad 1 hour ago|||

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.

anonymous908213 1 hour ago|||

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.

ameliaquining 1 hour ago||

Yes, but that's not really relevant to the controversy over the embargo.

anonymous908213 1 hour ago||

Neither the OP nor any comment in this chain of replies is about the embargo?

ameliaquining 59 minutes ago||

The controversy over the embargo is why the post was written and why we're talking about this at all.

anonymous908213 56 minutes ago||

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.

martinald 1 hour ago||||

But just because there isn't a working PoC on GitHub doesn't mean there isn't one and things aren't been actively exploited.

If you are a bad actor you probably don't share your PoC around as it means less boxes to hit.

ameliaquining 1 hour ago||

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.

mrheosuper 1 hour ago||||

With AI i think it's safe to assume it would only take hours after you give it what/where to look

hannasanarion 1 hour ago|||

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.

asddubs 32 minutes ago|||

ease is somewhat relevant initially, since it determines how quickly you have to patch before exploits start popping up. I would be extremely curious to see if anyone has been pwned by this already, especially before the public release of the patches (not that I doubt it, but I heard some people saying they saw attempts in their logs, but not really enough information to tell whether they were understanding their logs correctly. The situation just seems a bit murky and unclear to me).

j16sdiz 1 hour ago||

I guess the main takeaway is: we (humans? current methodology?) are bad at estimating how urgent a fix is or needs to be.

layer8 1 hour ago||

> So why was everyone so scared?

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

Genego 1 hour ago||

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.

charlesfries 29 minutes ago|||

For anyone wondering, this is the song https://soundcloud.com/marlonhoffstadt/highforever

skoll43 21 minutes ago|||

If has anime girl, it means is serious

yunnpp 49 minutes ago|||

What's up with these weird ass videos with the anime girls though?

adiabatichottub 1 hour ago|||

Also, High Forever track kind of bangs

ge96 34 minutes ago|||

the dancing anime girl is UI Shigure

nerosk 50 minutes ago||

the awful edit featuring an underage anime girl only exposes the childish, immature behavior of the people handling this situation, which makes this even more terrifying!

postalrat 14 minutes ago||

Since when is a 200+ year old immortal considered underage?

kgeist 1 hour ago||

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?

bunderbunder 1 hour ago||

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/did have a working exploit would have been enormous.

fwlr 17 minutes ago||

> why is it being proclaimed the worst vulnerability in years?

Also announced today: OpenAI’s software vulnerability initiative.

hn773746483 51 minutes ago||

Social media and "cybersecurity experts" had a big role in this. Stuff like "EU SAYS THIS IS A URGENT VULNERABILITY" and even the Prime Minister of Japan doing a nighttime PSA. They cite "the experts" posts on social media about the initial advisory, while the very same so-called experts share google search AI output mitigation strategies. 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 will never be a 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 ;)

noduerme 11 minutes ago||

OP seems to be implying that there's no way the UAF bug could be used to run arbitrary code with higher privileges than PHP itself, on a vanilla installation. I couldn't divine that from reading the CVE. Is that true...? Is that why you'd need PHP to exec an existing file or something? Or is that assumption just based on the fact that the PoCs so far rely on nerfing PHP? If the latter, it's a bit ironic to complain about everyone's judgment skewing toward Claude's while using Claude-generated code not doing it as circumstantial evidence that such a thing can't be done.

I'm no expert on UAF exploits. I guess one thing I'm wondering is whether the pointer to "freed" memory in this case is still pointing to memory reserved by the system for a PHP process, or if it's some address that's truly free and could be picked up by another process.

rectang 24 minutes ago||

According to "Today's PHP Security Release, and How We're Strengthening PHP Security" discussed at https://news.ycombinator.com/item?id=50182987

* Regarding one CVE, "Remote code execution was also confirmed on PHP-FPM through application-level code paths."

* The other CVE had "A use-after-free and worker crash were confirmed, and the reporter demonstrated remote code execution against a real-world application running on Apache with mod_php."

Since those exploits exist, I expect that LLMs will duplicate them soon.

amstan 1 hour ago||

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.

nickysielicki 7 minutes ago||

Docker images from Wordpress, joomla, and drupal were all exploitable.

https://www.wiz.io/blog/php2shell-php-rce

stickfigure 1 hour ago||

> It isn't a Log4J moment.

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.

bouncycastle 1 minute ago||

Core run time vulnerabilities in PHP, the language and runtime itself, are rare. I remember the days when an exploit in the JVM was a daily announcement. To the point where they had to ban java applets from the web.

Insimwytim 59 minutes ago|||

> It wasn't even a problem with the most popular logging framework at the time.

I can't say if it was most popular overall, but it (Log4Shell) was a nightmare for many F500 companies.

bunderbunder 46 minutes ago||

My employer at the time didn’t use log4j, but we were still plenty vulnerable. All sorts of open source packages we used had a transitive dependency on it.

bawolff 16 minutes ago||

I'd disagree. log4shell was a monster to patch and figure out what is and isn't vulnerable.

upgrading php is much easier.

Retr0id 1 hour ago|

I predict that this take will age poorly.

More comments...