Comment by DanielLestrange
2 years ago
If anything, the problem here is call_user_func, which when an attacker HAS ACCESS TO THE CODE, can be dangerous.
How on earth does emptying POST or REQUEST solve anything at all in regards? How on earth does, no matter what crap ACF added BEFORE the takeover, this "Fix" justify a hostile takeover? If or not there is a security issue with this code (which there IS, but not with POST or REQUEST data) is not even the matter anymore - it was and is posed and defended as a "urgent action to fix a security issue in a plugin the author has no access to"
And I repeat - there has not been any security fix!!
Read my root comment: > because the only relevant changes are actually neither introducing fixes, nor ever changing the plugin core code in a way that fixes security issues.
And I stand by that. Anyone reading this code can see it.
> How on earth does, no matter what crap ACF added BEFORE the takeover, this "Fix" justify a hostile takeover?
You can continue arguing with yourself, but I don't need to be there.
Why do you not actually provide some researched facts? I mean, I am all ears to stand corrected. Yet it appears all you (and other automatticians, and/or else employees) can do is deflect and talk down pretending you know better. Do you? Then teach your fellow humans where they are wrong. So far, I still have not been proven wrong about this pretended fix, which fixed nothing at all.
I don't intend to defend Automattic's shitty behavior at all, it's indisputably shitty and I take offense at your suggestions that I may think otherwise, as I never gave you any reason to believe that.
That said, you clearly seem to be confused about the nature of the issue being fixed there. It's clear from the existing code that the contract between this function and the callback getting executed is that the callback is expected to execute in a kind of a sanitized environment with restricted execution abilities.
You can argue that it's a really weak sandbox and that the whole design is smelly, and I'll agree with you. However, that's how this code was designed and that's what users are running on their servers, and that's how they expect it to behave. It prevents the callback from calling functions with `wp_` prefix and it disallows it from reading or making changes to user's POST data.
Now, if you find a way to circumvent those restrictions, it's an obvious security issue. Someone may have deployed some code that relied on that contract, and now that contract is known to be invalid (it always had been, but it wasn't known before). Therefore, stopping that from happening is a security fix.
It may be a poor fix - and in fact, this one is, as it's incomplete. But it's a fix. The upstream project recognized that and applied a similar, but a bit more thorough approach in its repo:
https://github.com/AdvancedCustomFields/acf/commit/a60034f8a...
It does exactly what the change we're discussing does, plus a bit more.
You still wouldn't convince me that it's a bulletproof sandbox and I already have some other ideas in my head on how it could potentially be circumvented after reading that code (though my PHP is so rusty I may very well be wrong), but the change in question is clearly a security fix, recognized and applied by both Automattic and WP Engine and I really can't understand why you're so keen on implying otherwise. As I already said, it only made your other (good) points seem weaker.
3 replies →