Any idea if Cloudflare in front of an unpatched site would prevent this? They did 2 updates already today to their managed rulesets but are not specifying what.
It's things like "under the attacker's feet" which completely throw me off. While trying to parse the text, my brain tries to imagine a surprised hacker.
Yeah but this AI music is worse than any AI produced code. They're both awful but I really lose all respect for people who think these Sumo songs sound good. Wow I hate that AI musician voice so much.
I just wrote almost the same thing (I start to write my
comments before I read what others say, so that it is not
influenced directly what I write). I am glad to come to the
same conclusion - this website is both visually interesting
as well as very annoying.
I'm pretty sure this is not the vulnerability that's still officially under embargo. I think I found the the two actual vulnerabilities (both UAFs and similar). I patched my own stuff (at least I hope so) and am mirroring traffic to a detector, very interested to see when I get the first hits. Unless I see actual exploit attempts or a full leak I think I'm not going to publish my patches yet.
You misread. He is saying that the multipart UAF vulnerability part of the overall exploit can't be fixed by session.upload_progress.enabled = off or any other ini option for that matter.
I can literally feel my eyes physically defocusing trying to read this, and I can’t help but conclude that, at a level below conscious thought, my brain is trying to defend itself from AI-generated text. Perhaps it is more of a cognitopoison than I explicitly knew.
Ctrl-Alt-R for reader view in Firefox, not that it makes the whole thing much more interesting to look at - we'll forget about it all soon enough anyway. Don't forget to tweak the default settings for reader view for a better experience.
If you use Nginx, you can temporarly block the subject by disallowing multipart sendings to PHP. This is quite a problem for a lot of forms, but way better that being hacked.
Here is an Nginx patch :
if ($http_content_type ~* "multipart") {
return 403;
}
You can also turn of session progress in php.ini as mentionned but that does not seem to cover every cases :
session.upload_progress.enabled = Off
It assumes PHP frees the upload progress data when it reloads the session. But PHP 8.4 (the one we use is 8.4.24, i don't know for other versions) calls Z_TRY_ADDREF(progress->data) to keep that data alive. The fake function call also seems to contain invalid fields.
This makes me question this particular PoC, not the official PHP security warning. I have not reproduced the exploit, so this is a concern based on reading the code, not proof that the real vulnerabilities cannot be exploited.
But anyway the CVE still exists, and the exploitation is tied to multipart, disabling it seems the best thing you can do now without shutting everything down.
How is this a better source, the current post is a PoC? This is just a warning...
You're not even reading the things you're saying are worse, and reccomending things that arent what you say they are (because you didnt read those either)
Announcing this thing and then putting an embargo on the fix for 24 hours is by far the most irresponsible thing internals has ever done and I have seen them do some insane shit in the past 20 years.
It is visually interesting but also annoying. I hate to
admit it, but as I grow older, I may get dumber and I
much prefer simplicity at all times.
As for PHP: it also is a bit weird how programming languages
have not yet all fixed existing bugs. Has not AI been used
to find bugs or assumed bugs? Why are bugs found in old
code still?
Why would they hand code a website for an exploit that they probably found 15 minutes before and will be fixed in a few hours? The copy should have been better though.
https://developers.cloudflare.com/waf/change-log/changelog/
Here is an Nginx patch : if ($http_content_type ~* "multipart") { return 403; }
You can also turn of session progress in php.ini as mentionned but that does not seem to cover every cases : session.upload_progress.enabled = Off
It assumes PHP frees the upload progress data when it reloads the session. But PHP 8.4 (the one we use is 8.4.24, i don't know for other versions) calls Z_TRY_ADDREF(progress->data) to keep that data alive. The fake function call also seems to contain invalid fields.
This makes me question this particular PoC, not the official PHP security warning. I have not reproduced the exploit, so this is a concern based on reading the code, not proof that the real vulnerabilities cannot be exploited.
But anyway the CVE still exists, and the exploitation is tied to multipart, disabling it seems the best thing you can do now without shutting everything down.
You're not even reading the things you're saying are worse, and reccomending things that arent what you say they are (because you didnt read those either)
<If "req('Content-Type') =~ /multipart/i"> Require all denied </If>
How fast will the repos be updated?
It is visually interesting but also annoying. I hate to admit it, but as I grow older, I may get dumber and I much prefer simplicity at all times.
As for PHP: it also is a bit weird how programming languages have not yet all fixed existing bugs. Has not AI been used to find bugs or assumed bugs? Why are bugs found in old code still?
>Leave Nothing
Cringe larping skiddie nonsense