Is php2shell only practical against extremely low-traffic targets?

[u/lucasluitjes]

If so, was the panic really necessary?

I looked at a bunch of PoCs, and it seems you need to do multiple consecutive requests to the same php worker process. In production systems that get a reasonable amount of traffic, you have multiple VMs/containers running multiple php processes behind a loadbalancer, and there will be constant background noise from legitimate traffic as well as scrapers and scanners.

The PoCs get around this because they experience zero traffic, know the exact number of processes, tie up all but one process with open connections and execute the attack against the remaining process.

On top of that, if you don't know the exact build, you need to try (assuming you have prepared exploits for every common build) exploits for the most popular x number of builds. So basically you would be DoS'ing a site for days or weeks, which would get noticed, and then you'll likely get WAF'd.

After spending crazy amount of time on remediation and then finding that the vuln is afaik significantly less scary than heartbleed/shellshock/log4shell, I'm confused. I did a little writeup explaining the above with more details (https://blog.luitjes.it/posts/i-want-my-wednesday-back/) but I keep wondering if I'm wrong (I do some infosec work occasionally but it's not like I'm a fulltime exploit dev).

I've seen a few posts saying this is hard to exploit because it needs to be customized per build, but nothing about having to DoS anything but the most low-traffic sites for days or weeks to get lucky enough to do two consecutive requests to the same php process.

[u/Classic_You_422]

After reading that writeup I think you hit the nail on the head, the panic was mostly driven by the CVSS score and people not understanding how modern php deployments actually work under load. Most security folks just saw "RCE in PHP" and lost their minds without thinking about the practical attack surface

[u/lucasluitjes → u/Classic_You_422]

Ah that makes sense. Maybe we need CVSSv5?

[u/KayDat → u/lucasluitjes]

No no, 4️⃣ is the hip number right now

[u/WhenTheRainsCome → u/Classic_You_422]

These events are always going to be possibly a huge catastrophe, or a huge overreaction. Most often nothing burgers.

We know more 4 days later, with the depth of info coming out largely because of the amazing level of global hype and impact. From the exploitation complexity, to the reason behind the ominous announcement and release, to the conflicting info on active exploitation in the wild, there's a lot of info and clarity that didn't exist on Oct 20, when decisions needed to be made.

Is it reasonable to say global business product owners and managemt teams should have bet their operations and customer data on 'huge overreaction' and left their apps online and unpatched?

We make those decisions with imperfect information and imperfect expertise. I think a lot of orgs showed amazing coordination and readiness given the circumstances.

[u/unvivid → u/Classic_You_422]

Nah, big security vendors and vuln research companies hyped the shit out of this. Plus the way it was leaked. With the Intel that was provided, the only sane way to react was to be cautious. Once POCs dropped and could be analyzed, only then was it apparent that things were over hyped. IMO the CVE is also mis-scored, way more complex than the 9.2 communicates.

I don't put this on any security teams, this is on vendors and vuln research hype machines and the obscene marketing that takes place around these vuln releases.

[u/Kenlak-Rubana88 → u/Classic_You_422]

CVSS really falls apart when the attack requires sustained interaction with a specific worker process, the scoring model just doesnt account for that kind of prerequisite

[u/Apprehensive_End1039]

to be fair, the people running random wordpress sites probably also aren't using modern HA best practices.

I agree from my understanding almost all heap massaging is hit-or-miss and the mitigations (pre-patch) reduced "possible" to "very highly unlikely", but due to the promiscuity of PHP and how often it jumpscares you in random legacy bullshit I don't believe the concern was unfounded.

As other folks noted, POV changes rapidly as more information becomes available. This one was especially a case of responsible disclosure having been thoroughly gun-jumped so, yanno... Scramble scramble scramble.

Are AI hype bros overselling this? IMO absolutely. "Black October" is another day in the fucking office.

[u/jirik-656]

Aren't sticky sessions give you same worker every time? It doesn't solve problem with consecuative requests tho

[u/sulliwan]

Most load balancers do some kind of sticky routing, so it's likely requests from same client will end up in the same service pod. But yes, it is absolutely not trivial to exploit against a production target and quite noisy.

[u/FowlSec]

Mandiant are saying that they've seen some PoCs working against default installs of mod-php. There have been zero reported breaches, and every red teamer/penetration tester/exploit dev I know (myself included), says this, right now, is nowhere near a functional exploit that will work in the wild.

Initial report from Wiz did say stale objects could lead to deserialisation vulnerabilities, so you either need that or some heap grooming/memory address leaks to get it working consistently.

However, the client that I told during a red team that functional exploits were not available very confidently told me in front of 20 people they their internal red team has a working exploit. I might ask them for it because they're obviously the best in the land.

[u/lumb3rjackZ → u/FowlSec]

My guess is the client’s side of the conversation went something like this internally -
Client to internal RT: “Do we have a way to test our systems?”
Internal RT: “We pulled some PoCs from GitHub from what we found on X and are standing up isolated VMs to test them, but it’s not real-world. One of our junior testers didn’t check the exploit code for one and rm -rf’ed their whole workstation somehow.”
Client to everything in the meeting: “We have a fully working exploit that we made ourselves and it works flawlessly!”

[u/danielmartinez22]

crowdstrike actually pushes back on the pinning thing specifically, prefork workers all share memory layout since they come off the same parent, so you dont need to isolate one single worker at all, any of them landing the request works the same way

[u/0dinscan]

Panic is good, panic pays bills.

[u/Audra_bunt → u/0dinscan]

omg so true

[u/acdha]

The problem is that you can’t reload a save game if you get it wrong. Gambling that it will stay hard to exploit (or that your WAF will block it) works in many cases but the failures cost a lot more (e.g. you can’t unbreach a PII leak) so defenders are often stuck with the asymmetry of spending regularly to avoid outliers. After Y2K, a lot of people said remediation had been unnecessary because nothing much broke, and I suspect the the same people would have been calling for heads if something they used had broken. 

The real takeaway here: everything you did by hand, everything which was hard to test, that’s what you want to automate so the next one is easier because they’re just going to keep coming. Three widespread CRITICALs in a week is unusual but not that much so that I’d bet against it happening again. 

[u/NudaVeritas1]

Interesting, thanks for the insights. I have the feeling (from what I saw in my job as a dev) that many government applications (or services within those) are basically a webserver within a DMZ. So that could be one of the bigger risks

[u/TheTarquin]

It entirely depends. On hosts with known software and ASLR disabled an attacker can get one-shot RCE. There are features and design patterns that make it harder.

But just because we have ASLR doesn't mean RCE vulns aren't a big deal.

[u/AYamHah]

I'm going to say no - you absolutely can exploit a target that receives significant traffic, but the number of attempts it would take for successful exploitation goes up significantly.

[u/Oreo-witty]

Thx for the source

Is there a similar insight/blog from a “trusted” source, which I could give my Boss? He went totally nuts at 10pm after reading on a general news site that “all websites“ are affected?
I think it would not be last time a CVSS would be published and everyone would panic

[u/Professional_Price89]

Hacker can gatcha, you cant.

[u/player1dk]

Have any of you had any of the POCs working ?

[u/IntrepidAir9704]

Das heutige Internet ist dafür gemacht, Panik zu verbreiten. Selbstverständlich sollte eine Schwachstelle schnell gepatched werden.

Ich habe kein allgemeines Wissen über die aktuelle PHP Schwachstelle und habe aus Vorsorge unsere Anwendungen auf allgemeinen Hinweis offline genommen und gepatched, da Auditoren sowas immer gutheißen, aber ich denke im Großen und Ganzen war die ganze Welle unnötig.

Wenn Microsoft CVSS 10.0 Schwachstellen veröffentlicht (was schon öfter vorgekommen ist), nimmt auch nicht sofort jede Firma Ihre gesamten Windows Server down.

Solange Klicks Geld bringen, versucht natürlich jeder mit diesen News viele Klicks zu generieren und die Menschheit in den Wahnsinn zu treiben. Als ob irgendjemand vor deiner Firewall nur darauf wartet einzubrechen.

[u/RoamingThomist]

Our guys have made an exploit that really does work.

It wasnt worth the hype. It gives a non-arbitrary RCE which will be really difficult to weaponise by threat actors. This was an OpenAI marketing event.

[u/Wyzkiewicz]

The panic allowed the forcing the update on some custom web app platforms that are normally hesitant to jump version numbers. Also forced the subject on updating the packaged PHP in CSGold Web Manager which is normally just left until there is a CSGold upgrade.

I got to abandon a couple instances in AWS that were using older CloudFormation stacks that were still AL2.

So all in all the hype allowed to clean up some obsolete stuff that otherwise people were hesitant to sunset. They see the executive summary that says PHP older than 8.2 won't get patched and this is one of those big hype ones that everyone asks about.

[u/Rogueshoten]

The problem is that everyone is thinking about websites in the traditional sense. And yes, typically those will have enough traffic that exploitation is hard.

But PHP is in a LOT of other things too. And a lot of those are not heavily trafficked. Cisco’s teleconferencing system, for example, is vulnerable…and not just the management interface. Citrix NetScaler too. And on and on…those are the bigger risk, I would say.