Comment by esquire_900
13 hours ago
I feel like all "non-inner-circle people" here are taken for a laugh. OpenAI and these security companies sat on this for 2 months, decided for themselves who gets access to an early fix, and then leave the rest out to dry while they failed to properly contain it.
The official interim fix for php8.5 [1] could have been published 24h ago, or even 2 weeks ago, without revealing any security details. Specifically once the POC came online. Would have been significantly more useful than these polished blogs.
Perhaps I'm missing something here, but the costs (dev/sre time, missed sales, potential data leaks and hacks) of the way that this was handled is significant.
[1] https://github.com/php/php-src/security/advisories/GHSA-6wmf...
>OpenAI and these security companies sat on this for 2 months
these security companies reported it 2 months ago. it took a month for the php security team to acknowledge it and another month for the php team to develop & release the patch.
if you're going to be upset at anyone it should not be the reporters.
>The official interim fix for php8.5 [1] could have been published 24h ago, or even 2 weeks ago, without revealing any security details.
publishing the fix = publishing the security details.
This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails they get.
If I had details on a RCE like this I'd report it but if I got no response for a WEEK I'd be trying other venues.
I imagine more details will come out over the coming days, but it’s not uncommon for severity to be under-estimated in the beginning; and then “oh shit” as you dig deeper.
We don’t know when it went from a “memory safety issue” to “php2shell/RCE”.
Calif’s report is a little light on timelines, but reading between the lines, it seems they took a while to turn this into an actually exploitable vulnerability.
Finally, at least pre-LLM (and maybe a bit outdated now), responsible security disclosure norms is that you usually do wait for vendor (up to 90d) if there’s no signs of active exploitation. Even if it’s a RCE. Actually, especially if it’s a RCE.
The last thing you wanna do is go pinging random non-security PHP contributors or maintainers and have it leak with zero patch. That is truly the worst outcome.
Yes, this is bad, but also, it’s apparently been bad for decades; and it could’ve been much worse.
4 replies →
>This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails
i highly doubt it. these are pretty big names in the security sector who have plenty of experience reporting high severity vulns.
1 reply →
I've said elsewhere I am sick to death of reading AI written "security disclosures". Even for genuine issues, it just saps my motivation to fix them.
That said, PHP team handled this poorly. How does letting everyone know so they can "prepare" help anyone at all. It just creates panic.
3 replies →
Are you victim blaming the reporter?
If you have a bad process, fix the process.
>if you're going to be upset at anyone it should not be the reporters.
Everyone is just upset by AI. So they want to blame the side that was involved with AI. It's like how cops automatically assume black people are criminals.
Why does the PHP security team need to acknowledge it and develop the fix? It's open source software.
If you want an orderly fast global rollout you need to have the maintenance team and distributors working together.
So if Wiz produced their own patch to PHP, and Calif produced their own (slightly different) patch, and OpenAI produced their own, which version should I use, as a user of PHP? Should I manually merge them? Is Calif's better than Wiz's? Is OpenAI's better than Calif's? Are they complementary?
2 replies →
So anybody can just push out a new release of PHP?
14 replies →
What's the other choice? OpenAI et al could have developed a patch (for all we know they did) but you need the PHP team's participation to get it out. The alternative would be to fork the project and put up a forked release with the fix, which would have been incredibly disruptive.
2 replies →
What would you have a security team for then?
2 replies →
Because...that's what the PHP security team does?
No one needs to use their work, or indeed PHP at all.
But that's why the PHP security team exists.
2 replies →
One concern with the current environment is that as soon as a release comes out for such an important open source project, people will immediately point bots at the release to look for changes that might be related to existing security issues. This means that putting out a quick out-of-band release is guaranteed to result in people racing to exploit the problem before many even know there is an update out.
Whether keeping the update quiet and including it in the next normal release, where there are more trees obscuring the wood that is the security concern, and announcing the bug a short time later once anyone using distro updates or otherwise keeping on top of things have updated, would be safer overall than what has happened today is up for debate. I can think of arguments in both directions.
--------
[1] which does have a slight whiff of AI marketing about it - would a human-found issue, without the option of a big AI company to claim some credit, have been handled differently?
This is not a "concern", this is literally what happens. Even prior to AI vulnerability scanning, release notes and diffs for any normal release or security patch of popular software were analysed and used to develop exploits, which could then be applied against non-upgraded instances. Nowadays, AI is doing this en masse and automatically producing exploits. And, as has been demonstrated, nowadays even the rumour of a major security bug is enough for people to find it, as people will immediately burn huge volumes of tokens looking for it.
Nor can you just keep it quiet and smuggle it out in a regular release as you suggest. For one thing, changes in important software are be linked to commits and have pull requests, reviews, etc. Changes without these will immediately raise suspicion, as either a malicious change snuck into a release, or as a "quiet" fix to a major vulnerability, completely undermining the purpose of keeping it quiet in the first place. Moreover, major vulnerability fixes cannot be "quiet", because the whole point is to get as many people as possible to upgrade as quickly as possible. If PHP (or whoever) push out a release containing a major security fix, but don't make this clear, then many people will be in no rush to upgrade, and will get pwned.
> This is not a "concern", this is literally what happens.
Sorry, I should have been specific: the concern is that this will happen faster than even the more fastidious admins (or daily or even hourly automated checks) will spot and apply updates.
> nowadays even the rumour
I think a lot fewer people would have paid attention at all without the rumour. Some ne'er-do-wells might have scanned a larger update for security issues otherwise, but I suspect most of those spending tokens on PHP this week would not have bothered had there just been a standard maintenance release that may or may not have included changes for a security issue that may (but probably not) have been so globally significant.
That is, at least in part, why the question of how to manage the release of updates like this is not a settled debate.
> then many people will be in no rush to upgrade, and will get pwned.
The worst case that we may be heading towards is that for any services on public facing infrastructure we might have to automatically apply updates with little or no time to verify, just to try be ahead of the ne'er-do-wells, with even superficial updates not mentioning the changes until a short time after to avoid giving clues to those who will scan for security issues if any such is mentioned (or nothing is mentioned - saying nothing about a security-only update only works if you say nothing about all updates, and you don't want to hold off on security-only updates on a slow moving project that might not have a non-security patch for quite some time).
It's not possible to publish a security patch for an open source software report without revealing security details anymore (and as of the past couple weeks I would not count on being able to do that for closed source binaries either). The moment you push publish everyone knows previous versions are compromised
“OpenAI and these security companies sat on this for 2 months”
I don’t think this what happened at all, and even less so to specifically call out OpenAI.
The issue was discovered using their model, it was disclosed, and the PHP team took months to address it. Eventually it leaked.
This is a process / people failure that does not involve the people responsible for discovering it.
this is the same tired conversation whenever coordinated disclosure happens
"we the people deserve to know about vulns on day 0"
oh yeah? and what happens when a 0 day is released?
it's the same ignorance over and over.
You can't do secret releases, people will figure out what you added or changed.
But they could have accelerated the patch release once the embargo was broken and rumors of a PoC started going around. There was no need to wait 12+h today until the release.
Maybe the NSA ‘requested’ some time to use the exploit on some high value targets.
Sure, it’s PHP, but plenty of companies or organisations might have some PHP running somewhere; and once you’re in, lateral movement becomes a lot easier.
The NSA does not need to "request" time to use an n-day vuln. They have more 0-days than you can imagine.
They literally employ full-time Vulnerability Researchers doing nothing but 0-day discovery and PoC creation 24/7 to add to their horde. Plus contracting with the MIC for their full-time VRs for the occasional project.
Exactly. Something like this is often the NSA realizing one of their pet vulns is being exploited in the wild by someone “not them” and so they burn it.
Php core security team decided who gets to know. The patch was huge it took that long.
See PHP foundation blog post on their timeline
> OpenAI and these security companies sat on this for 2 months
The PHP team knew about it since September 21st.
Maximizing the PR value...
> OpenAI and these security companies sat on this for 2 months, decided for themselves who gets access to an early fix
Amazingly, AWS Linux has not been patched yet.
And then they proceeded to cripple any of my agents working on this.
Of course it was OAI that decided those things, not the U.S. Government
it was neither OAI or the US government.