So yeah that ACF/SCF security issue really was bogus. When the PoC gets published on November 7th, I am "going scorched earth" 🤭 on Matt's reasoning behind necessitating the SCF fork.
Just remember the first line of Matt's post:
"On behalf of the WordPress security team, I am announcing that we are invoking [...] of the plugin directory guidelines and are forking Advanced Custom Fields (ACF) into a new plugin [...] SCF has been updated to remove commercial upsells and fix a security problem."
As promised, here is my PoC take on the ACF takeover resulting from Automattic’s report.
First, understand this:
1. Anyone with admin access can manage ACF
2. Anyone with admin access can edit plugin files (if enabled on the host) or upload/install a new plugin (except multisite where disallowed per-site as non-super admins)
Now, assuming that item 2 above is locked down and there are NO plugins that allow for eval of PHP or uploading/editing PHP files on a site...
(continued)
ACF has an option for post types and taxonomies that lets you specify a function to use for the metabox callback (a built-in WordPress feature of register_post_type and register_taxonomy). This can only be a callable string so no PHP gets evaluated here.
BUT there's some unsavory functions in WordPress itself that are not nonced (tsk tsk) and leverages $_POST. Sounds like a core security concern IMO but sure let's game the ACF issue out in more detail next.
(continued)
In the vulnerable versions of ACF/SCF, you could provide the callback "wp_write_post". That function itself will attempt to create/update a post using $_POST data. No nonce checking, but it DOES check that the user has caps.
So someone has to do these things to do bad things:
1. As an admin, set this metabox callback in a way that you'll probably realize it happened since you will be going to normal edit post screens for your post type and things will be messed up.
(continued)
Then..
2. Create and host a hack that forces you, an unsuspecting editor+ to unwillingly submit a $_POST to the impacted edit post screen on your own site. This is the gotcha IMO, if you have admin access to do this, this entire PoC hack falls apart!
3. Admin unwillingly submits the $_POST data and triggers the "bad stuff".
This is just bonkers. This is the super bad security issue that necessitated Matt Mullenweg forking/taking over ACF entirely.
@skc Playing devil's advocate here, but once the JSON import is in place, wouldn't an editor be able to create a page with embedded javascript? Probably true if they have "unfiltered html". They would be able to create a post that contains XSS code perhaps?
On multisite, going from regular admin to network admin can be a significant privilege escalation.
SKC 🏳️🌈
Roy Tanck