WordPress plugin WooCommerce arbitrary file deletion vulnerability resolution

   The permission processing mechanism of WordPress is mainly achieved by providing different functions to different roles. When the store administrator role is defined, it will assign the edit_users function to this role, so that they can directly manage the store's customer accounts. The entire permission allocation process occurs during the installation process of the plugin. Woocommerce/includes/class wc install. php:

//Shop manager role.add_role(       'shop_manager',      // Internal name of the new role       'Shop manager',      // The label for displaying       array(               // Capabilities                ⋮              'read_private_posts'     => true,              'edit_users'             => true,              'edit_posts'             => true,                ⋮       ));

The role permission information will be stored in the database using WordPress core settings, which means that the user role is now independent of the plugin. Even if the plugin is not enabled, it will not affect the relevant role permissions.

When an authenticated user attempts to modify other user information, the current_user_can() function is called, ensuring that only privileged users can perform this operation. Example of calling the current_user_can() function:

$target_user_id= $_GET['target_user_id'];if(current_user_can('edit_user',$target_user_id)) {    edit_user($target_user_id);}

The verification logic for the call is as follows: Does this user have permission to modify a specific user using the ID $target_user_id?

By default, the edit_users feature allows authorized users (such as store administrators) to edit other users, even administrator users, and then perform operations such as password updates. For security reasons, WooCommerce needs to specify whether the store administrator can edit users, so the plugin needs to add a meta permission function. The Meta function can be called by current_user_can(). By default, the value returned by the function is true, but the value returned by the meta permission function can determine whether the current user can perform such an operation. The following is the abstract function code for the WooCommerce meta permission filter:

function disallow_editing_of_admins( $capability, $target_user_id ) {       // If the user is an admin return false anddisallow the action    if($capability == "edit_user"&& user_is_admin($target_user_id)) {        return false;    } else {        return true;    }}add_filter('map_meta_cap', 'disallow_editing_of_admins');

For example, when current_user_can ('edit_user ', 1) is called, the filter will determine whether the user with ID 1 ($target_user_id) is an administrator and decide whether to allow the user to operate based on the result.

Store administrators disable plugins

By default, only administrators can disable plugins. However, this vulnerability allows store administrators to delete any writable files on the server, so we can disable WordPress from loading the plugin by deleting WooCommerce's main file - woocommerce.php.

This file deletion vulnerability exists in the logging function of WooCommerce, where logs are stored as. log files in the wp content directory. When the store administrator wants to delete the log file, he needs to submit the file name with the GET parameter. The code snippet shown below is the vulnerable part:

woocommerce/includes/admin/class-wc-admin-status.php

class WC_Admin_Status{    public static function remove_log()    {    ⋮        $log_handler = newWC_Log_Handler_File();       $log_handler->remove(wp_unslash($_REQUEST['handle']));}

woocommerce/includes/log-handlers/class-wc-log-handler-file.php

class WC_Log_Handler_File extends WC_Log_Handler{    public function remove($handle)    {    ⋮        $file = trailingslashit(WC_LOG_DIR) .$handle;    ⋮unlink($file);

The problem here is that the file name ($handle) will be added to the log directory (wp content/wc logs/) and then passed to the unlink() function. When setting "$handle../../plugins/wocommerce 3.45/wocommerce. php", the file wp content/wc logs/..// Plugins/woecommerce-3.45/woecommerce.php will be deleted and will result in WooCommerce being disabled.