Comment by john_strinlai
13 hours ago
>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.
According to this post, one of the researchers was a former PHP security lead who already knew about the bug since 2004. So I'd assume they would be taken as credible by the current team https://calif.io/php2shell/
3 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.
and they also have plenty of exposure to their motherships burning money on LLMs
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.
If you provide forewarning, system administrators around the world in various time zones can get ready to update at the same hour the fix is released, which is very important. Being hours late is not acceptable for a vulnerability like this.
1 reply →
[dead]
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?
That does happen with downversion software. Red Hat may distribute a backported patch to some component which isn't the same as Canonical or Debian's.
Most users, who don't know the answer to your questions, rely on the distro to figure this out (and often pay good money for it).
They already were in communication with each other. They could have come together and decided on one that mitigates the issues they've found.
So anybody can just push out a new release of PHP?
Yes, someone could have published a safe version for people to use for the 2 months to get the actual fix done.
9 replies →
Sort of by definition of open-source, yes. It's just that nobody downstream is likely to accept Joe Public's random fork of PHP.
3 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.
I'm glad they didn't do anything disruptive, then. Like wind the world's CIOs up into a frenzy of FUD and bring thousands of servers down in a coordinated panic attack synchronised to the minute.
Imagine if they had just patched the code and rolled it out with an advisory?! Oh my GOD! Won't someone think of Sam Altman and his huge pile of debt?!
1 reply →
What would you have a security team for then?
To handle the official solution and drive long term changes to reduce similar security bugs from happening again. The current PHP security team does not seem capable to promptly release a fix, so having a community fix first seems preferable.
Mitigating a bug and developing a proper solution that is maintainable long term and supports future changes being made to the software take different amounts of time to develop.
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.
If it takes 2 months to do fix a massive security issue, it's best if someone else steps up to the plate to fix it.
1 reply →