I want my Wednesday back
42 points by lucasluitjes
42 points by lucasluitjes
Problem here is that there has been a steady stream of local privilege escalation bugs for linux for the past ... what, 18 months? Combine any of these with any kind of RCE and you're toast. So the danger is real, especially as people are usually lazy in patching LPE bugs on dedicated servers.
You don’t need to escalate to root if PHP already gives you all the access you need, like reading the web app’s database.
yeah, and the PHP maintainers issued that advisory which described it as very high severity and turning off the server as the only way to mitigate before the patch. so everybody did that, because that's the correct action when a language maintainer tells you to.
I hope people don't get a false sense of security that leads them to under-react next time.
I'll be interested to learn more, once there's been full analysis, about whether other security people agree that the maintainers made the right call.
I'll evaluate this from my perspective, as someone who self hosts Nextcloud, and try to judge the points for myself.
Even a moderately popular production website will have multiple web VMs/containers running multiple php workers behind a load balancer and constant bot traffic.
This may be true, but I don't. I'm betting most people who just self host a PHP thing don't.
Let’s say you try this for the 50 most popular php/OS combinations, and any number of workers between 10 and 1010.
Against myself, you could've looked at the latest version of Nextcloud's official Docker image. It has my PHP version, my OS version, and my number of workers. I haven't changed the defaults.
(stuff about WAF)
I don't run a WAF, and I have seen security people complain about them and essentially call them useless. Maybe they're wrong, and maybe I should've been running a WAF. In any case, Nextcloud's default configuration doesn't include one, and I don't think most other self hosted services do either.
Rate limiting is obviously a good idea independent of WAFs but since we're talking about 153 requests here I don't know that that would've kicked in.
Against very low-traffic websites that do not have any bot protection, leak information about their version, running close to stock configuration, you might get lucky.
Well there you have it. That's me, and probably most people who self host Nextcloud.
I don't know how typical my situation is, but I'm feeling good about having taken both my Nextcloud instances offline once the vulnerability was teased.
Not extremely clued in to the whole chain of events, so my reading might be off, but it seems to me that the panic was fuelled by the recent over-confidence in, and over-reliance on, AI agents and LLMs. As soon as rumours of the exploit hit the internet, everyone and their grandma put their chatbots on the task - and chatbots are very good at very quickly producing a large volume of results that look very convincing but only half-work or don't hold up of the further scrutiny, and also immediately try to attack targets if controlled by a black hat. The result was a deluge of "confimed exploits" and "active attacks" hitting the internet as soon as the news broke.
People scrambling to respond to this probably themselves had to resort to LLMs to analyze the situation due to the lack of reliable information and the speed in which everything was moving, and knowing how the current models are primed to overemphasize security issues (and be overly dramatic in general) it would not surprise me if they defaulted to confirming people's worst fears: "The exploit has been thoroughly corroborated. This isn’t just a bug. It’s a genuinely profound vulnerability woven into a load-bearing part of the whole internet."
Combine this with a pre-existing fear that AI actually would be able to exploit something like this in a catastropic manner, and a reasonable better-safe-than-sorry stance, and the reports of widespread severe exploits become very believable even for experts.
Actually analyzing the situation and the real impact still required human effort and thoughtful analysis, but such an approach moves with a glacial speed in comparison.
If the language maintainers themselves say it's a bad vuln and to take the server offline before patches come out then I don't really blame most orgs for reacting as they did. I suspect there was also a bit of a telephone game going on from https://lobste.rs/s/t73wqi/just_rumour_bug_is_enough_find_security where automated attacks starting in minutes from patches being pushed was conflated with finding said vuln + developing a reliable poc that works everywhere in minutes of knowing that a patch will be pushed.
I do blame the vendors who irresponsibly use such vulns for clout (calif couldn't be bothered to check dates before uploading their poc video?), break embargoes they agreed to (chainguard!) and put others at risk. And also everyone's trying to take credit for finding it? See: https://shellsharks.com/php2chaos
This all just leaves a very bad taste in my mouth seeing how vendors act.
I myself specifically don't blame chainguard, they published images only once the patch was already virtually as good as leaked, and with exploit attempts in the wild.
Has there been any compromise resulting from this yet?
Also unclear, what I did see is all the usual suspects (cloudflare, aws) claiming to seen attack attempts. I am not sure I have seen any reports about websites being compromised.
The Doylist answer is that no one who would be compromised from this, especially after it went fully public, would have capacity to know that they got compromised.
I apologize for nitpicking, but I don't understand in what sense this is Doylist. reality doesn't have a writer whose reasoning we are party to and can analyze? is it some sort of metaphor?
Yeah, I was aiming for a metaphor, might have misused it. Maybe a rephrasing will be clearer: as a corollary, any organisation running PHP that didn't patch or take down the site within few hours of the public patches being available is perhaps best considered to be unable to monitor their own systems too.