Top
Best
New

Posted by zkldi 3 hours ago

There isn't an easy exploit for this PHP vulnerability(eliastaylor.com)
155 points | 68 commentspage 2
richardbarosky 2 hours ago|
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.

https://www.php2shell.com/

https://patchtheplanet.org/

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

https://calif.io/php2shell/

anonymous908213 1 hour ago|
People mistake OpenAI and Anthropic for AI companies, but they are in fact primarily in the business of marketing, and business is good.
ameliaquining 1 hour ago||
Every business is in the business of marketing, that's a meaningless distinction.
taikahessu 10 minutes ago|||
There's no ai in mrketng.
easterncalculus 1 hour ago||
Related LiveOverflow video about fake exploits going around https://www.youtube.com/watch?v=7CiZmq2llDg

That said, OP is basically full of shit. This is absolutely exploitable and people are going to just assume the platform and ABI and spray it against the internet, particularly hoping for mod_php.

1over137 22 minutes ago||
>This is absolutely exploitable...

OK, can you share a working one so we can test that our servers are fixed?

noduerme 37 minutes ago||
Aren't most PHP sites out there running mod_php anyway?
Ardren 32 seconds ago||
15 years ago absolutely. Most modern sites will be running php-fpm (or maybe FrankenPHP)
squidlib 2 hours ago||
https://aws.amazon.com/security/security-bulletins/2026-143-...??
Insimwytim 1 hour ago||
It's also weird that it seem to has overshadowed certificates incident, which, to me, appears to be of at least the same magnitude of impact.
Gigachad 1 hour ago|
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.

Insimwytim 58 minutes ago|||

  Most non-browser TLS clients (so basically everything else, with default settings), things like curl, Python, Node, Go, Java, git, package managers and every script and daemon you've got, do three things that matter here: they trust a CA bundle on disk, they don't check revocation by default, and they don't check CT. So the fact that eMudhra and Sectigo have revoked these intermediates doesn't help them at all. [1]
[1] https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-key... ( https://news.ycombinator.com/item?id=50177916 )
cesarb 1 hour ago|||
It's not just IoT devices. It's also a very very long tail of programs which for some reason have their own copy of the CA certificates list, either because they don't trust the system's one, want to work identically on all platforms, have a severe case of not-invented-here, or all three at the same time (looking at you, Java...)
commandersaki 1 hour ago||
My take:

I have had this take but for things like exploiting with a DRAM interposer ala Battering RAM. They say it's a low cost attack, but the amount of obstacles you need to overcome (including having root on the system and physical access) is intractable to virtually everyone, and a nation state wouldn't go to that kind of gymnastics when it is more than likely there is a quicker and easier way in.

But this? I doubt any high value targets will be exploited in the wild since news travelled fast and from what I can see pretty much most took preventative action. Looks like pretty much everyone heeded the warning and suggestions. It'll mostly be a nothing burger like Heartbleed. There'll be of course low hanging fruit of unpatched servers out there, but anything of importance would have already had active maintenance and patching.

Now that Calif has released the details, I'm sure there'll be a contingent that can actively and easily exploit this, either now or very soon, with or without the guidance of LLMs.

But yeah if someone said Battering RAM, I would say fuggedabout it, but if someone said PHP vulnerability with a CVE of 9.2, I would say patch it ASAP or bring the servers down until you can.

zer00eyz 1 hour ago|
> but anything of importance would have already had active maintenance and patching

Mostly because people either "did it" or yelled long enough and loud enough that it "got done". There is a saying about horses and water, but some people needed to be dragged, kicking and screaming and have their faces shoved in the well.

When headlines like "there wasn't an easy exploit" come out I have burned a lot of good will, on what people will perceive as "nothing burger". The security space has a knack for making a complete mockery of itself and then wondering why no one seems to give a fuck.

"I'm getting too old for this shit" really does apply to today.

tamimio 1 hour ago||
>script kiddie

Get on time, pa, they are called LLM kiddie now

0xbadcafebee 1 hour ago|
RCE is incredibly dangerous not because it lets you execute arbitrary code, but because it lets you execute some code. Code you're not supposed to execute. As soon as someone can do that, all they have to do is probe until they find something to chain.

Almost every system on the internet has some local code you can chain to gain root, or a way to put some in place. It gets worse when it affects legacy systems, because they're the bastard stepchild of security. RCE on a box that hasn't been patched since Obama's first term is what little blackhats' dreams are made of. And developers are way too lazy to intentionally design their apps into different privilege domains to protect against chaining. Unless your app runs chroot() (is my neckbeard showing?) or in a container with nothing but a Go binary, somebody can LFI it.

A crack in the door is plenty of space to get a crowbar in (especially with interpreted languages).

More comments...