Debian has, though only for current stable (updates for oldstable and oldoldstable apparently about to drop) which might imply they had no advanced access to the update so could not pre-test and release immediately upon the coordinated announcement.
Not true. I was able to `aptitude update` and `aptitude full-upgrade` before 10:00 AM EST (9:50 AM) and received the new php8.* packages and upgraded fine.
Still no update for ubuntu 20.04 which has support via ESM, even though the patch is available for php 7.4. There are a lot of people using older servers which still have ESM support.
PHP 8.5.4-0ubuntu1.5 (the fixed version for Ubuntu 26.04) has been downloadable for me via apt from security.ubuntu.com for about 30 minutes. Perhaps check to see that you're not using a different mirror?
If you mean docker official images, it's just the "community" maintaining it, eg "some dudes". By no means should you consider it a mechanism to get timely security updates, I've seen horrible lag on that before.
Most of docker is like this. Images provided by volunteers, and not related to the project. Using docker images you don't maintain yourself, and at least don't upgrade yourself, is not the best recipe for security.
There are different approaches and it all comes down to who you trust. I don't think there's universal answer. If you have money, find image provider who's serious about security and hopefully they'll provide patches images quickly. Otherwise using Debian packages is a good default I think.
Honestly I don't even understand why so many docker images prefer to build software from sources, rather than just installing them from debian repositories.
And if you're using a docker package it's often JUST BECAUSE the host Debian/Ubuntu server is out of date for things you need, and Docker's the easiest way to "patch" that.
I'm starting to suspect that they actually got the notice the same time we did, because if they got the patches there should be no reason it wasn't already built and ready to go (unless they're scared that "our build servers are public and everyone will know" so they literally held everything off until the release which seems so counterproductive as to be ... well, open-source silliness).
Mindboggling, wtf don't they release it if its ready and exploit is in the wild, its a lot of time until 14:00 UTC and a lot of websites will be breached.
They should have shut up, released a new stealth PHP version and told everyone to update ASAP. They gave way to many details ahead allowing some AI agents to find the vulnerability within half an hour...
The update was withheld because releasing it without notifying major providers and distros would turn it into the same race, with ai having a release is the same thing as a disclosure.
This would've worked if other people were able to shut up about it. Because its existence got leaked they posted the announcement
There is no functional difference between doing just an announcement and doing an announcement with a series of builds containing the patch while withholding the source code. You do understand that right?
A message as vague as "there is a major RCE somewhere in this entire programming language" is usually pretty safe. We'll see how the details actually got out in this situation and whether the announcement caused it, but it still took a while. If you put out a patched build people will find and decompile the changes nearly instantly.
One security provider put "session.upload_progress.enabled, session.use_strict_mode" in the SEO keywords for their initial announcement, which was probably a good enough clue to feed to an LLM. https://web.archive.org/web/20261021005246/https://sansec.io... (go to page source, search for session.upload_progress). At least one person on Twitter saw this: https://x.com/its5q/status/2112700519261032497 Of course there's enough people who knew about this that the exploit vector may have leaked out to the general public through a different source as well.
Yep. It's probably one of a handful of functions. It'll be based on request input, a script doesn't have to call the function, and it works with default configuration. I bet it takes a half hour for AI to figure it out.
Php4 -> 5 was a massive change including zendengine2 and an overhaul of many modules. Fortunately that information really doesn't tell us much. (Also it was a year of work between the first beta and the release - many changes at that time)
I mean an agent can walk those changes, but it's close to just walking all the whole source / research from scratch at that point.
A patched build is strictly more information, and you'd only need to cross correlate between the two.
At this point shipping the build already may have been the best option but not necessarily everyone is actually able to ship yet. And this is of course assuming the actual vulnerability is the same one as the PoCs that are being tried, and not something even nastier instead
The reason we (used to) have responsible disclosure timelines is so that the information & software to fix vulnerabilities can be assessed, organised, written up. Builds could get built, attackers and defenders find out at once. But crucially, defenders could use the normal channels to fix their installations and be sure they'd covered themselves.
When a PoC drops before that timeline is up (like now!) the attackers get a head start because they have less work to do - just figure out how to use it to their payload, start spraying it out.
Meanwhile maintainers don't want release an incomplete or misunderstood fix. Otherwise they'd risk people updating and believing that they're safe when they're not. Even a fragment of misinformation from an official channel will spread like wildfire. So when you demand fixes NOW you're demanding something that may not be completely understood.
So (I'm sure we'll find out but) I believe this 2pm timeline was already as soon as is human possible for the PHP team to do a repsonsible job, and not risk us having to come back tomorrow for a fix to the fix.
LLMs gives attackers the advantage for a while, and it means we'll have to tighten the secrecy around even the rumour of a vulnerability.
Humans generally have the need for a process called "sleep" where people are generally required to go horizontal and unconscious for at least 6 hours per day.
No, ‘responsible disclosure’ was and always has been a response from vendors not patching their software or building secure software to start with, and trying to frame researchers as responsible for their shoddy work.
As far as I can tell, there is no proper mitigation beyond patching. Unless we count turning off your service as a mitigation. Cloudflare is currently busy playing whack-a-mole with new vectors so it’s probably not feasible to properly mitigate it on the edge either.
Improper mitigation is still better than literally nothing - a simple "this may not cover everything, but block POST at the edge might help" can go a long way.
So it looks like Hetzner is doing the same thing OVHCloud did with EncroChat and SkyECC. But hey, we have GDPR, keep your data hosted in the EU it is very "safe" there (ironic).
> Now closing https service is obviously just a temporary fix
Probably the best starting point would be to edit the robots.txt file and disallow LLM bots there.
Currently the file allows all bots: http://acme.com/robots.txt
The only way to temporarely get rid of my tinnitus (completely gone or at least very reduced for up to 30 seconds) is to listen to this beep tone from 8 to 12 KHZ: https://www.youtube.com/watch?v=qNf9nzvnd1k
apparently the phenomenon is called residual inhibition. If only there was a way to make this work permanently...
Whoah, that's weird. I listened to the whole sweep just so I could match it to my tinnitus (turns out: about 10khz), but when I paused it to re-evaluate my own tinnitus, it wasn't there. I mean, it's back now. But still, weird.
Also works pretty great. If I need a few minutes of actual silence I use that. I think people using TENS and other therapies are basically stimulating the same nerves to treat it.
reply